I'm kinda new to C++. I know how to set C++ version with CMake, but don't know how to set C++ version in Bazel.
Maybe set with the copts parameter in cc_libary but I have to set this in every cc_libary?
To set the standard using the default C++ toolchain in Bazel you can set environment variable BAZEL_CXXOPTS, e.g. BAZEL_CXXOPTS="-std=c++14". You can also set it from the command line or from .bazelrc using --repo_env=BAZEL_CXXOPTS. : is the flag separator.
Alternatively you can pass --cxxopt to Bazel, or put it into .bazelrc, e.g. --cxxopt='-std=c++11'.
The robust solution to specifying C++ toolchain in Bazel is to use the CcToolchainConfigInfo. See the documentation at https://docs.bazel.build/versions/master/tutorial/cc-toolchain-config.html and https://docs.bazel.build/versions/master/cc-toolchain-config-reference.html.
bazel build --cxxopt='-std=c++11' main:hello-world This would work, but I wonder if there's way to set this cxxopt globally, like CMAKE_CXX_FLAGS.
Add this to your .bazelrc next to your WORKSPACE:
build --action_env=BAZEL_CXXOPTS="-std=c++20"
If you want to set multiple options, separate them with a colon:
build --action_env=BAZEL_CXXOPTS="-std=c++20:-Werror"
It is kind of a workaround as bazel sets an environment variable which bazel then uses. But it works.
BTW: build --cxxopt=-std=c++20 in the .bazelrc did not work form me.
Related
I have written a program prg which can be run using bash with some subcommands like so
$ prg subcommand1
Output of subcomman1
$ prg subcommand2
Output of subcomman2
The program is written in C++11 and compiled with CMake (3.10+).
Now, I'd like to add another optional command, say optional_subcommand.
Optional - in a sense that a user can decide whether to compile program with it when configuring Cake.
To clarify, when the code is not compiled withoptional_subcommand support, the output should be something along this lines
$ prg optional_subcommand
Option not supported...
The optional_subcommand requires external library to be installed. Hence find_package(SomeLib REQUIRED) must be invoked at some stage by CMake. The code for optional_subcommand requires this library to compile.
All I can think of is writing some dummy code for optional_subcommand which is then replaced on request by CMake. I think this can be achieved be asking CMake to overwrite, say optional_subcommand.cpp with either dummy or not.
Is proposed solution sensible or perhaps there is a better way to achieve this?
CMake can define a preprocessor symbol and add extra files to your target (below, prg) if needed:
if(SomeLib_FOUND)
target_compile_definitions(prg PUBLIC HAVE_SOMELIB)
target_sources(prg PRIVATE src/optional_subcommand.cpp)
endif()
You can then wrap the command dispatching code for optional_subcommand with #ifdef HAVE_SOMELIB.
Having read the Meson site pages (which are generally high quality), I'm still unsure about the intended best practice to handle different options for different buildtypes.
So to specify a debug build:
meson [srcdir] --buildtype=debug
Or to specify a release build:
meson [srcdir] --buildtype=release
However, if I want to add b_sanitize=address (or other arbitrary complex set of arguments) only for debug builds and b_ndebug=true only for release builds, I would do:
meson [srcdir] --buildtype=debug -Db_sanitize=address ...
meson [srcdir] --buildtype=release -Db_ndebug=true ...
However, it's more of a pain to add a bunch of custom arguments on the command line, and to me it seems neater to put that in the meson.build file.
So I know I can set some built in options thusly:
project('myproject', ['cpp'],
default_options : ['cpp_std=c++14',
'b_ndebug=true'])
But they are unconditionally set.
So a condition would look something like this:
if get_option('buildtype').startswith('release')
add_project_arguments('-DNDEBUG', language : ['cpp'])
endif
Which is one way to do it, however, it would seem the b_ndebug=true way would be preferred to add_project_arguments('-DNDEBUG'), because it is portable.
How would the portable-style build options be conditionally set within the Meson script?
Additionally, b_sanitize=address is set without any test whether the compiler supports it. I would prefer for it to check first if it is supported (because the library might be missing, for example):
if meson.get_compiler('cpp').has_link_argument('-fsanitize=address')
add_project_arguments('-fsanitize=address', language : ['cpp'])
add_project_link_arguments('-fsanitize=address', language : ['cpp'])
endif
Is it possible to have the built-in portable-style build options (such as b_sanitize) have a check if they are supported?
I'm still unsure about the intended best practice to handle different options for different buildtypes
The intended best practice is to use meson configure to set/change the "buildtype" options as you need it. You don't have to do it "all at once and forever". But, of course, you can still have several distinct build trees (say, "debug" and "release") to speed up the process.
How would the portable-style build options be conditionally set within the Meson script?
Talking of b_ndebug, you can use the special value: ['b_ndebug=if-release'], which does exactly what you want. Also, you should take into account, that several GNU-style command-line arguments in meson are always portable, due to the internal compiler-specific substitutions. If I remember correctly, these include: -D, -I, -L and -l.
However, in general, changing "buildtype" options inside a script (except default_options, which are meant to be overwritten by meson setup/configure), is discouraged, and meson intentionally lacks set_option() function.
Is it possible to have the built-in portable-style build options (such as b_sanitize) have a check if they are supported?
AFAIK, no, except has_argument() you've used above. However, if some build option, like b_sanitize, is not supported by the underlying compiler, then it will be automatically set to void, so using it shouldn't break anything.
I am writing a C++ program using gtkmm as the window library and autotools as my build system. In my Makefile.am, I install the icon as follows:
icondir = $(datadir)/icons/hicolor/scalable/apps
icon_DATA = $(top_srcdir)/appname.svg
EDIT: changed from prefix to datadir
This results in appname.svg being copied to $(datadir)/icons/hicolor/scalable/apps when the program is installed. In my C++ code, I would like to access the icon at runtime for a window decoration:
string iconPath = DATADIR + "/icons/hicolor/scalable/apps/appname.svg";
// do stuff with the icon
I am unsure how to go about obtaining DATADIR for this purpose. I could use relative paths, but then moving the binary would break the icon, which seems evident of hackery. I figure that there should be a special way to handle icons separate from general data, since people can install 3rd party icon packs. So, I have two questions:
What is the standard way of installing and using icons with autotools/C++/gtkmm?
Edit: gtkmm has an IconTheme class that is the standard way to use icons in gtkmm. It appears that I add_resource_path() (for which I still need the installation prefix), and then I can use the library to obtain the icon by name.
What is the general method with autotools/C++ to access the autotools installation prefix?
To convey data determined by configure to your source files, the primary methods available are to write them in a header that your sources #include or to define them as macros on the compiler command line. These are handled most conveniently via the AC_DEFINE Autoconf macro. Under some circumstances, you might also consider converting source files to templates for configure to process, but except inasmuch as Autoconf itself uses an internal version of that technique to build config.h (when that is requested), I wouldn't normally recommend it.
HOWEVER, the installation prefix and other installation directories are special cases. They are not finally set until you actually run make. Even if you set them via the configure's command-line options, you can still override that by specifying different values on the make command line. Thus, it is not safe to rely on AC_DEFINE for this particular purpose, and in fact, doing so may not work at all (will not work for prefix itself).
Instead, you should specify the appropriate macro definition in a command-line option that is evaluated at make time. You can do this for all targets being built by setting the AM_CPPFLAGS variable in your Makefile.am files, as demonstrated in another answer. That particular example sets the specified symbol to be a macro that expands to a C string literal containing the prefix. Alternatively, you could consider defining the whole icon directory as a symbol. If you need it only for one target out of several then you might prefer setting the appropriate onetarget_CPPFLAGS variable.
As an aside, do note that $(prefix)/icons/hicolor/scalable/apps is a nonstandard choice for the installation directory for your icon. That will typically resolve to something like /usr/local/icons/hicolor/scalable/apps. The conventional choice would be $(datadir)/icons/hicolor/scalable/apps, which will resolve to something like /usr/local/share/icons/hicolor/scalable/apps.
In your Makefile.am, use the following
AM_CPPFLAGS = -DPREFIX='"$(prefix)"'
See Defining Directories in autoconf's manual.
I am trying to build SOCI on Windows with a different library suffix using the CMAKE_SHARED_LIBRARY_SUFFIX option, but the script seems to ignore it.
Here is the command I run in a batch file:
cmake^
-G "NMake Makefiles"^
-DCMAKE_BUILD_TYPE=Release^
-DCMAKE_SHARED_LIBRARY_SUFFIX="-vc140-x64-mt.dll"^
..\soci.3.2.3
The documentation does not say anything about the CMAKE_SHARED_LIBRARY_SUFFIX option, but the core/CMakeLists.txt script uses it to define the SOCI_LIB_SUFFIX option, which is reported on the screen when cmake is run. However, its value is always ".dll" instead of "-vc140-x64-mt.dll", so it must be overwritten somewhere I don't know.
Any idea why is this happening and how fix it?
I have a library with a bunch of different configuration options. We usually configure the build with cmake-gui and ticking a few checkboxes.
I want to automate this into a .sh script using just cmake.
e.g.
In GUI -> selects a bunch of different options
equivalent cmake command -> cmake -D CMAKE_XXX=X -D CMAKE_XXY=XXY [a bunch of options here] ..
How can I find the "equivalent" cmake command-line command to any arbitrary configuration I choose from the GUI?
The equivalent cmake command to cache a variable is explained here (-D option). Note that previous documentation was ambiguous, so take care of always checking the latest one.
Basically:
-D<var>:<type>=<value>
You have to specify also the type to have the variable cached in the same way as through your cmake-gui procedure. Note that variable definition is necessary only the first time: if not specified anymore, the cached value will be used.
cmake-gui generates CMakeVars.txt and CMakeCache.txt files in the build directory once you click "Configure" button. They cache all variables you configured through the GUI.
Had the same question ... and as you asked I looking up some of the options in the menu and found it. Menu Tools -> Show My Changes
Bringing up an Dialog with an edit field with content for command line options or cache file options.
yeah
p.s. I used cmake 3.11.1
just read file named like CMakeCache.txt (iirc) in the root of build directory and see variable names there
You can write a file containing all variables you want to set with set(<var_name> <value>) and pass this file to the CMake call via -C:
cmake -C <fileWithInitialValues> <pathToSrcDir>
Documentation:
https://cmake.org/cmake/help/v3.3/manual/cmake.1.html
This should would similar with cmake-gui and ccmake, but it is not a pure solution with the graphic interface.