I wasn't sure how to set the title for this.
I basically have a code base that I build with cmake; now I would like to know if it's safe to invoke cmake itself on the same cache more than 1 time.
For example in the dir /path I'm building a cache with
cmake -DVAR=VALUE < more flags >
and then in a second step I invoke cmake again in the same directory /path with another set of flags
cmake -DANOTHER_VAR=ANOTHER_VALUE < more flags >
at this point there are some guarantees that what is inside /path is the result of both commands ? It depends on how the CMakeLists is written ?
My building system that I use over cmake could be simplified a little thanks to this steps, that's why I'm asking.
Yes, it's OK to do this. Actually, when you change something in your CMakeLists.txt's and then run make in build folder, CMake invokes cmake . there to regenerate the cache.
Beside that, -DVAR=VALUE is an intended way for setting vars in the generated cache, as well as -UVAR.
The only exception is changing vars like CMAKE_C_COMPILER or CMAKE_CXX_COMPILER. If you alter them with cmake -DCMAKE_C_COMPILER=newcc ., CMake would wipe your cache and generate it from scratch.
Related
Some years ago on Ubuntu 16.0.4 I've used this library: git clone https://github.com/Beckhoff/ADS and using only the make command I got build, compile and finally on the main directory I found a file called AdsLib-Linux.a and maybe nothing more than this.
Now I'm on Ubuntu 20.04 I need this library once again but this times make dosn't produce the same output and looking forth to the ReadMe instructions I finally used that instead of make:
meson build
ninja -C build
That now create a new directory build but no .a file as before on the root directory. Instead a new file in the build directory libADSLib.a is there. The same thing happens using right the make command.
Maybe the author changed over the years something on the config files or the behavior of the tools have changed, but I cannot get the former file anymore and I need it for other referencing code that now is not executing anymore.
Looking to the MakeFile I found that in the example folder, differently from the one on the parent directory, the MakeFile has something like that:
$(warning ATTENTION make is deprecated and superseeded by meson)
...
${PROGRAM}: LIB_NAME = ../AdsLib-${OS_NAME}.a
...
But all i've tried reading the guides on meson and ninja about setup, configure, build, and so on, did not produce anymore that file.
I've tried also to first build and then copy all files form the example folder to the parent directory and then build again, but again no .a file there.
How's the right way to configure the build process corectly so that this -Linux.a file is created. Or if not possibile anymore, what does it now produce I can use instead of what produced before?
Meson is a build system generator, similar to CMake or somewhat like ./configure, you need to run meson, then run ninja to actually build something.
You need to run both meson and ninja:
meson setup builddir
ninja -C builddir
Once you do that successfully, there will be a libAdsLib.a inside the builddir directory.
Let me correct a bit #dcbaker, according to their README you should setup build as build directory:
# configure meson to build the library into "build" dir
meson build
# let ninja build the library
ninja -C build
Of course, in general, it shouldn't be specific, but their example code is written in a weird way so this path is hard-coded. So, to use the example:
# configure meson to build example into "build" dir
meson example/build example
# let ninja build the example
ninja -C example/build
# and run the example
./example/build/example
About the library: it's now libAdsLib.a and produced in build directory. The name is set here and it's now in linux naming style, the old one - not. So, you have options:
Update your configuration/build files (Makefile?) where you use it
Copy or make symbolic link, e.g.
$ ln -s <>/build/libAdsLib.a <target_path>/AdsLib-Linux.a
Above it's very dependent on your development environment, do you have installation or setup scripts for it? do you permissions to modify/configure parameters for target application? do you need to support both old and new names? - many questions not related to original question about meson.
I'm packaging a software (neko) for Debian. The software uses CMake for building. I already have everything setup and it builds nicely. Now, I want to add some additional tests on top of the upstream tests, so I override dh_auto_test in debian/rules as follows:
override_dh_auto_test:
dh_auto_test
cd <build_dir> && ./bin/nekotools boot test.n && ./bin/test
The problem is that I don't know what is the CMake build directory (<build_dir> as written above) thus cannot figure out the paths to the build outputs. Is there a variable that points to the build directory?
I find out that I can specify the build directory as follows:
%:
dh $# --builddirectory=foo
It is mentioned in the dh manpage.
However, I still would like to know whether there is a variable that stores the build directory even if I'm not using --builddirectory...
I add to my project gtest as external project, and for clean install
I download and recompile it, as shown in the code below. I works fine, but in every single development step, when I add a test case, checks the repository, delaying the execution, and when I am off-net, even the make step fails.
How can I explain CMake, that this download, check, etc, is ONLY needed if I make a build form scratch? (I.e. when gtest is available, no action needed?)
# Add gtest
ExternalProject_Add(
googletest
SVN_REPOSITORY http://googletest.googlecode.com/svn/trunk/
SVN_REVISION -r 660
TIMEOUT 10
PATCH_COMMAND svn patch ${CMAKE_SOURCE_DIR}/gtest.patch ${CMAKE_BINARY_DIR}/ThirdParty/src/googletest
# Force separate output paths for debug and release builds to allow easy
# identification of correct lib in subsequent TARGET_LINK_LIBRARIES commands
CMAKE_ARGS -DCMAKE_BUILD_TYPE=${CMAKE_BUILD_TYPE}
-DCMAKE_ARCHIVE_OUTPUT_DIRECTORY_DEBUG:PATH=DebugLibs
-DCMAKE_ARCHIVE_OUTPUT_DIRECTORY_RELEASE:PATH=ReleaseLibs
-Dgtest_force_shared_crt=ON
# Disable install step
INSTALL_COMMAND ""
# Wrap download, configure and build steps in a script to log output
LOG_DOWNLOAD ON
LOG_CONFIGURE ON
LOG_BUILD ON)
The ExternalProject_Add function has the UPDATE_COMMAND option. Setting this option to empty string "", just like you do for INSTALL_COMMAND, disables the update step.
According to documentation for CMake 3.4, there is also a UPDATE_DISCONNECTED option to achieve the same result. I didn't try it myself, so I'm not sure it works as I understand.
I've read the entire ATLAS installation guide, and it says all you need to build shared (.so) libraries is to pass the --shared flag to the configure script. However, when I build, the only .so files that appear in my lib folder are libsatlas.so and libtatlas.so, though the guide says that there should be six others:
libatlas.so, libcblas.so, libf77blas.so, liblapack.so, libptcblas.so, libptf77blas.so
After installation some of the tests fail because these libraries are missing. Furthermore, FFPACK wants these libraries during installation.
Has anyone encountered this? What am I doing incorrectly?
In my experience, it's a lot more complex than that, see our EasyBuild implementation of the ATLAS build procedure at https://github.com/hpcugent/easybuild-easyblocks/blob/master/easybuild/easyblocks/a/atlas.py .
We needed to:
enable the -fPIC compiler option
run 'make shared cshared ptshared cptshared' in the 'lib' directory
We're not even using --shared for configure, probably because it doesn't do much.
If you want to build ATLAS (and whatever you will be linking it with) without headaches, look into EasyBuild.
(disclaimer: I'm a developer for EasyBuild)
First if you have incorrectly specified the --force-tids flag for configure then the parallel libs won't build. To check this you can run make ptcheck. I have question regarding the specification of this flag here
Then if I examine my resulting ATLAS Makefile it says " ... only when atlas is built to one lib" and indeed only two "fat" libs are constructed: libsatlas.so and libtatlas.so.
I quess you can either link FFPACK against those libs or change the resulting ATLAS Makefile to contain the targets you need (Which won't be too hard since the static libs are available).
I had to manually create links to the .so.3 files.
So the versioned library files existed, but not the files the cmake was looking for.
Running
sudo ln -s libatlas.so.3 libatlas.so
sudo ln -s libcblas.so.3 libcblas.so
sudo ln -s liblapack_atlas.so.3
(I didn't build the cblas, atlas or lapack but installed them with apt-get. Wondering why the links were not automatically created).
Has anyone seen something like this:
when running make in a project using autotools, it always rebuils everyhing. Running with make -d, shows that make looks for foo.lo files and because they are not found, always recompiles foo.c.
It seems to be related to builddir != srcdir.
The .lo files are of course in the builddir. But apparently make or libtool are expecting them somewhere else:
Debug output lookgs like this:
Prerequisite /path/to/srcdir/foo.h' is older than targetfoo.lo'.
/path/to/builddir/.deps/foo.Plo:1 Must remake target `foo.lo'.
Update It seems the problem is caused by AC_PROG_LIBTOOL. According to the documentation it expects a variable called top_builddir to be set to the builddirectory. What is the standard way to set it? Is there a autoconf macro for this?
A libtool update solved this problem