I need to use make-3.8.2 version for compiling code. I have modified makefile in following way.
export PATH := /home/make-3.82/bin:$(PATH)
I am able to change PATH variable But it Invoke current make version which is make-3.7.6.
if I set manually in terminal than it's work fine which is also correct as it takes from Path
So is it possible to override make file version or any init function where we can override make file version after running make command
In simple words, check make file version and if it's not set make file version 3.8.2 or report any error ( any option is fine)
My Purpose is, we can handle make file version inside Makefile rather than any .cshrc or .bashrc to avoid any enviroment setup
I have doing following way in makefile.
ifneq ($(MAKE_VERSION), 3.82)
$(error Please add /home/make-3.82/bin in PATH enviroment and re run)
endif
If you set PATH from your makefile make already runs in the old version. I don't know under which OS/shell you are working. For bash you have to set your PATH var in ~/.bashrc.
Related
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.
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?
While giving the cmake command I am using the flag "-DWITH_DAY=1" option as the flag.
This flag is available in the code and wokrs fine.
But when I want to build other ibrary using the same code but without this flag I need to erase the definition of this flag because in my code I have statements like
"if(NOT DEFINED WITH_DAY)"
But when I do a cmake without this flag the WITH_DAY still remains defined! and hence my build fails.
It only works if I remove the CMakeCache.txt file or the entire build directory.
I want is to be disabled if I do not specify it in the command line.
You should run cmake -U WITH_DAY . before building other library. It's because CMake saves WITH_DAY's value in the cache (CMakeCache.txt).
Alternatively, as #Caduchon has mentioned, you can make WITH_DAY an option and change your if statement to just
if(WITH_DAY)
I compiled my program with intel C++ compiler for windows (from Intel Composer 2011), and got an error message that libmmdd.lib cannot be found. I googled this problem, and some people said that I have to reinstall my compiler, and I did; however, that didn't resolve the problem, so I started looking in the intel compiler directory, and found that this file (and other required libraries as well) are located at
%CompilerDirectory%\compiler\lib\ia32
It doesn't make sense to write in the make file the whole absolute path of the libraries, so I started searching, and I could only find that %mklroot% points to the math kernel directory. And even with a -L%mklroot%/../compiler/lib/ia32 approach for linking I couldn't link to the libraries correctly, so eventually I did a lame move to solve the problem, which is, I copied every file the linker asks for to the source directory, and so was the problem temporarily solved.
Since this way of solving the problem isn't the best one, I wonder if there's a way to link to those libraries without having to copy the files. It's strange because the compiler should find its own libraries alone, but... I don't know...!
Any ideas? is there something like, %compilerroot%, that points to the compiler directory and that I could put in my makefile (or actually my qmake, since I'm using Qt).
Thanks for any efforts :-)
Instead of using %mklroot% try $$(mklroot) or $(mklroot).
You can find the explanation here:
Variables can be used to store the contents of environment variables.
These can be evaluated at the time that qmake is run, or included in
the generated Makefile for evaluation when the project is built.
To obtain the contents of an environment value when qmakeis run, use
the $$(...) operator:
DESTDIR = $$(PWD)
message(The project will be installed in $$DESTDIR)
In the above assignment, the value of the PWD environment variable is
read when the project file is processed.
To obtain the contents of an environment value at the time when the
generated Makefile is processed, use the $(...) operator:
DESTDIR = $$(PWD)
message(The project will be installed in $$DESTDIR)
DESTDIR = $(PWD)
message(The project will be installed in the value of PWD)
message(when the Makefile is processed.)
In the above assignment, the value of PWD is read immediately when the
project file is processed, but $(PWD) is assigned to DESTDIR in the
generated Makefile. This makes the build process more flexible as long
as the environment variable is set correctly when the Makefile is
processed.
EDIT:
It is strange that neither $$(mklroot) nor $(mklroot) gave you the result you would expect. I did a simple test to verify what I wrote above:
Opened a Command Prompt
Created a new environment variable 'mklroot' with a test value: set mklroot=C:\intel_libs
Verified the result of the previos step: echo %mklroot%. I got C:\intel_libs
Placed your 3 qmake functions at the end of my .pro file:
warning($(%MKLROOT%))
warning($(MKLROOT))
warning($$(MKLROOT))
Ran qmake: qmake. The result:
Project WARNING:
Project WARNING: c:\intel_libs
Project WARNING: c:\intel_libs
As you can see the 2nd and the 3rd warning() displayed the string I set to the environment variable.
I'm using Autoconf to build my c++ project. It uses third party code which is also built with the help of Autoconf/Automake. So in my configure.ac I've got the following line:
AC_CONFIG_SUBDIRS([subdirectoryname])
Everything works fine, but I also use the feature to let tests be automatically made if make check is executed - which is done by the third party code as well. Because these tests take a while it's annoying to execute them each time I want to test my own code. So is there any way to avoid that the check option is passed to the subdirectory's Makefile?
Update: Overriding check-recursive does not seem to be an option, as my top-level Makefile.am looks (more or less) like this:
SUBDIRS=library src
So disabling checking on this level would also disable the checking inside my src folder. And that's not what I want to achieve. I just want to disable the checking in the library directory.
Overriding check-recursive in your Makefile.am should work:
check-recursive:
#true
or, if you only wanted to check in a specific directory:
check-recursive:
$(MAKE) -C src check
according to the autoconf manual, it will execute a configure.gnu script in the subdirectory if it finds one. Theoretically that could be a script which adds a --disable-tests or similar option to a call to ./configure
That said, I've yet to get this to work on a project of my own. :-/