I know there is exist option for C to check the existing libraries using conf.CheckLib .
env=Environment()
conf=Configure(env)
if not conf.CheckLib('lapack'):
print 'Did not find Lapack, exiting!'
Exit(1)
How do I modify it for Fortran libraries
You have to roll your own CheckFortranLib(), based on the actual definition of CheckLib() in the source files SConf.py and Conftest.py.
If you succeed in this, please consider contributing your code to the SCons contrib repo. It would help the SCons project a lot.
Related
I have run into a rather strange problem with Google Tests.
In my project, I am using externalProject_add in order to download google tests and add them into my project. In my function, I believe I am asking for the project to be built, and then installed into a specific directory:
ExternalProject_Add(gTest_download
URL ${GTEST_url}
URL_HASH ${GTEST_hash}
UPDATE_COMMAND ""
BUILD_COMMAND cmake --build . --target install
CMAKE_CACHE_ARGS
-DCMAKE_C_COMPILER:PATH=${Compiler_C}
-DCMAKE_CXX_COMPILER:PATH=${Compiler_CXX}
-DBUILD_SHARED_LIBS:BOOL=ON
-DCMAKE_INSTALL_PREFIX:PATH=<BINARY_DIR>/installation
)
I can then tell the program where all the source files are living with this:
ExternalProject_Get_Property(gTest_download BINARY_DIR)
set(gTest_LIBRARY_DIR ${BINARY_DIR}/installation/lib CACHE INTERNAL "Google Test Binary Dir")
set(gTest_INCLUDE_DIR ${BINARY_DIR}/installation/include CACHE INTERNAL "Google Test Include Dir")
However, when I try to run a cmake test with protobufs I get the run time error:
./Protobuf_test: error while loading shared libraries: libgmock.so.1.11.0: cannot open shared object file: No such file or directory
Which is super odd, because I know I specifically told the program where to find the libraries in the same externalProject_add file:
set(gTest_LIBRARIES
${gTest_LIBRARY_DIR}/${prefix}gmock${suffix}
${gTest_LIBRARY_DIR}/${prefix}gmock_main${suffix}
${gTest_LIBRARY_DIR}/${prefix}gtest${suffix}
${gTest_LIBRARY_DIR}/${prefix}gtest_main${suffix}
CACHE INTERNAL "Google Test Libraries"
)
Where ${prefix} is "lib" and ${suffix} is ".lib". And I make sure to link them in my CMakeLists.txt file properly by doing target_link_libraries(Protobuf_test ${gTest_LIBRARIES} ${protobuf_LIBRARIES}) ex:
CUSTOM_PROTOBUF_GENERATE_CPP(PROTO_SRCS PROTO_HDS ${CMAKE_CURRENT_LIST_DIR} hello.proto)
include_directories(
${protoBuf_INCLUDE_DIR}
${gTest_INCLUDE_DIR}
${CMAKE_CURRENT_LIST_DIR}
)
add_executable(Protobuf_test protobuf_test.cc ${PROTO_SRCS} ${PROTO_HDS})
add_dependencies(Protobuf_test
gTest_download
protoBuf_download
)
target_link_libraries(Protobuf_test
${gTest_LIBRARIES}
${protoBuf_LIBRARIES}
)
add_test(NAME testing_protobuf COMMAND Protobuf_test)
So I went into the installation folder which is located in d/linuxBuild/lib/src/gTest_download-build/installation/lib and confirmed it exists there. I then ran ldd libgmock.so and got the following output:
libgtest.so.1.11.0 => not found
Which I thought was odd as well. gtest is in the same directory! How is that possible? So I ran ldd on gmock_main:
libgmock.so.1.11.0 => not found
libgtest.so.1.11.0 => not found
So now I have two libraries that are in the same directory however they cannot be found. Confused, I decide to go to where the libraries should have originally installed to and copied over from. So two folders up: d/linuxBuild/lib/src/gTest_download-build. I then go into that folders lib folder and verify the libraries are there. I then run the same ldd command on gmock:
libgtest.so.1.11.0 => /mnt/d/linuxBuild/lib/src/gTest_download-build/lib/libgtest.so.1.11.0 (0x00007fb651729000)
I'm confused by this and again, run it on gmock_main:
libgmock.so.1.11.0 => /mnt/d/linuxBuild/lib/src/gTest_download-build/lib/libgmock.so.1.11.0 (0x00007f58b0db3000)
libgtest.so.1.11.0 => /mnt/d/linuxBuild/lib/src/gTest_download-build/lib/libgtest.so.1.11.0 (0x00007f58b0c9c000)
I am sorry for the lengthy question, but I need to know what happened here? Why is it when I install the libraries the links break from each other and they don't know their locations compared to the ones in the original installation path? Did their symbolic links break? Did I do something incorrectly in the CMake build? I'm scratching my head on this problem since I have never encountered this before. Any advice would be greatly appreciated.
Forget about externalProject_add and use FetchContent / FetchContent_MakeAvailable, especially when dealing with CMake-ready projects:
See https://cmake.org/cmake/help/latest/module/FetchContent.html for details
include(FetchContent)
FetchContent_Declare(
googletest
GIT_REPOSITORY https://github.com/google/googletest.git
GIT_TAG release-1.11.0
)
FetchContent_MakeAvailable(googletest)
# ...
target_link_libraries(Protobuf_test
PRIVATE
gmock_main
${protoBuf_LIBRARIES}
)
This way, you are linking against the gmock_main target, which will set up your libraries, includes, and any indirect dependencies correctly like any cmake project added via add_subdirectory() or find_package().
I'm having trouble trying to do something seemingly very simple with CMake 2.8.11.2 . I have a folder with two files:
-- CMAkeLists.txt --
add_executable(test test.c)
target_link_libraries (test somelib)
-- test.c --
// Some c code
when I create a build directory and issue cmake .., cmake runs with the following output:
C:\Users\Enis\workspace_kepler\tmp\build>cmake ..
-- The C compiler identification is unknown
-- The CXX compiler identification is unknown
-- Configuring done
-- Generating done
-- Build files have been written to: C:/Users/Enis/workspace_kepler/tmp/build
And an MSVC 2012 solution is generated inside the build folder (as I have MSVC2012 installed). Now, the problem is that when I open that solution and check the linker configuration of the test project under Properties->Configuration Properties->Linker->Input->Additional Dependencies I see that somelib is added as ;-lsomelib.lib and visual studio doesn't like that. It links successfuly only if I change that to somelib.lib manually.
What am I doing wrong? Why does CMake make such a simple mistake? What can I do to change the prefix it generates?
I faced the same issue. The root of the problem is CMAKE_LINK_LIBRARY_FLAG but I have no idea what sets it. Resetting it, demonstrated in the snippet below, should help you.
set(CMAKE_LINK_LIBRARY_FLAG "")
I am trying to complete the installation for some software. According to which I have to add path. I am not getting it how to do that. Please guide me how to do the following steps.
Add the path to Rpa/Tk headers:
-I/usr/include/rpatk
To link to the Rpa/Tk libraries on Linux add the following link options:
-lrpa -lrvm -lrex -lrlib -lm
RVM library uses some math functions from the system math library, that is why you must include '-lm' to include the math library to your project in addition to the Rpa/Tk built libraries:
librpa librex librvm librlib
http://www.rpasearch.com/rpatk/doc/doxygen/rpadoc/html/rpatk_build.html
this will be within your configure script -- you will need to hack this and add the paths to where gcc/cc gets called
give the link to the actual tar.gz
looking at the example code: http://www.rpasearch.com/rpatk/doc/doxygen/rpadoc/html/js-tokenizer_8c-example.html
gcc -I/usr/include/rpatk -o js-tokenizer js-tokenizer.c -lrex -lrlib
so in short :
export LD_LIBRARY_PATH=/usr/include/rpatk:/usr/local/lib:/lib:/usr/lib
then running the configure may fix the issue
where the bit in bold would the path to the includes for this project
I am not sure exactly what my question is as I get seriously turned around by autoconf/automake/libtoolize etc. Several of us are trying to autoconferize mbsystem. I've thrown a repo up of the work to date here:
https://bitbucket.org/schwehr/mbsystem
I'm trying to improve the netcdf setup to use nc-config, but am uncertain how to do this correctly. I am working on configure.in. It seems unable to find a header with AC_CHECK_HEADER("netcdfcpp.h") after INCLUDES="$INCLUDES ``$nc_config --cflags``" (pardon the incorrect back ticks) as taken from the gdl netcdf check. What is the correct way to update the path from nc-config --cflags?
http://gnudatalanguage.cvs.sourceforge.net/viewvc/gnudatalanguage/gdl/configure.in?revision=1.121
I then tried to use AX_PATH_GENERIC and get stuck on this error with m4_include([m4/ax_path_generic.m4])
Running autoconf ...
configure.in:29: error: possibly undefined macro: AC_SUBST
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.
configure:12992: error: possibly undefined macro: AC_MSG_RESULT
Any help in getting better at creating a netcdf check that actually will work with funky non-standard install locations via nc-config and figuring out how to properly put a macro in the m4 directory would be a huge help.
A pointer to a package doing this really cleanly would be a super help. I've been looking at the netcdf, gdal, geos and gdl sources for examples. And things like the octopus netcdf check do not use nc-config... http://www.tddft.org/trac/octopus/browser/trunk/m4/netcdf.m4
The current setup with fink for netcdf 4.x:
nc-config --cflags --libs
-I/sw/opt/netcdf7/include -I/sw/include
-L/sw/opt/netcdf7/lib -lnetcdf
Thanks!
See Makefile.am: How to use curl-config and xml2-config in configure.ac? and substitute xml2/curl by netcdf.
Just use
PKG_CHECK_MODULES([libnetcdf], [netcdf])
in configure.ac, and then, in Makefile.am:
AM_CPPFLAGS = ${libnetcdf_CFLAGS}
bin_PROGRAMS = foo
foo_SOURCES = ...
foo_LDADD = ${libnetcdf_LIBS}
The "correct" way to use a third party m4 macro is to use aclocal (usually via automake) to generate aclocal.m4. If you are using automake, just add
ACLOCAL_AMFLAGS = -I m4
to Makefile.am and put
AC_CONFIG_MACRO_DIR([m4])
in configure.ac (after renaming configure.in).
If you are not using automake, add '-I m4' when you invoke aclocal. If you are not using aclocal, then you'll have to append the definition of the macro to the end of aclocal.m4 (and be careful to never run aclocal, as that will overwrite the file.)
There is no good example of a clean way to use conf scripts to do a build because using such scripts is an inherently flawed approach. A slightly cleaner approach is to stop using custom scripts and use pkg-config via PKG_CHECK_MODULES, but the cleanest way to do this is to educate your users. If the user wants to install the library in funky non-standard locations then they need to be educated enough to set LDFLAGS and CPPFLAGS appropriately.
I guess this would be a generic question on including libraries with existing makefiles within cmake; but here's my context -
I'm trying to include scintilla in another CMake project, and I have the following problem:
On Linux, scintilla has a makefile in (say) the ${CMAKE_CURRENT_SOURCE_DIR}/scintilla/gtk directory; if you run make in that directory (as usual), you get a ${CMAKE_CURRENT_SOURCE_DIR}/scintilla/bin/scintilla.a file - which (I guess) is the static library.
Now, if I'd try to use cmake's ADD_LIBRARY, I'd have to manually specify the sources of scintilla within cmake - and I'd rather not mess with that, given I already have a makefile. So, I'd rather call the usual scintilla make - and then instruct CMAKE to somehow refer to the resulting scintilla.a. (I guess that this then would not ensure cross-platform compatibility - but note that currently cross-platform is not an issue for me; I'd just like to build scintilla as part of this project that already uses cmake, only within Linux)
So, I've tried a bit with this:
ADD_CUSTOM_COMMAND(
OUTPUT scintilla.a
COMMAND ${CMAKE_MAKE_PROGRAM}
WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}/scintilla/gtk
COMMENT "Original scintilla makefile target" )
... but then, add_custom_command adds a "target with no output"; so I'm trying several approach to build upon that, all of which fail (errors given as comment):
ADD_CUSTOM_TARGET(scintilla STATIC DEPENDS scintilla.a) # Target "scintilla" of type UTILITY may not be linked into another target.
ADD_LIBRARY(scintilla STATIC DEPENDS scintilla.a) # Cannot find source file "DEPENDS".
ADD_LIBRARY(scintilla STATIC) # You have called ADD_LIBRARY for library scintilla without any source files.
ADD_DEPENDENCIES(scintilla scintilla.a)
I'm obviously quote a noob with cmake - so, is it possible at all to have cmake run a pre-existing makefile, and "capture" its output library file, such that other components of the cmake project can link against it?
Many thanks for any answers,
Cheers!
EDIT: possible duplicate: CMake: how do i depend on output from a custom target? - Stack Overflow - however, here the breakage seems to be due to the need to specifically have a library that the rest of the cmake project would recognize...
Another related: cmake - adding a custom command with the file name as a target - Stack Overflow; however, it specifically builds an executable from source files (which I wanted to avoid)..
You could also use imported targets and a custom target like this:
# set the output destination
set(SCINTILLA_LIBRARY ${CMAKE_CURRENT_SOURCE_DIR}/scintilla/gtk/scintilla.a)
# create a custom target called build_scintilla that is part of ALL
# and will run each time you type make
add_custom_target(build_scintilla ALL
COMMAND ${CMAKE_MAKE_PROGRAM}
WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}/scintilla/gtk
COMMENT "Original scintilla makefile target")
# now create an imported static target
add_library(scintilla STATIC IMPORTED)
# Import target "scintilla" for configuration ""
set_property(TARGET scintilla APPEND PROPERTY IMPORTED_CONFIGURATIONS NOCONFIG)
set_target_properties(scintilla PROPERTIES
IMPORTED_LOCATION_NOCONFIG "${SCINTILLA_LIBRARY}")
# now you can use scintilla as if it were a regular cmake built target in your project
add_dependencies(scintilla build_scintilla)
add_executable(foo foo.c)
target_link_libraries(foo scintilla)
# note, this will only work on linux/unix platforms, also it does building
# in the source tree which is also sort of bad style and keeps out of source
# builds from working.
OK, I think I have it somewhat; basically, in the CMakeLists.txt that build scintilla, I used this only:
ADD_CUSTOM_TARGET(
scintilla.a ALL
COMMAND ${CMAKE_MAKE_PROGRAM}
WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}/scintilla/gtk
COMMENT "Original scintilla makefile target" )
... and then, the slightly more complicated part, was to find the correct cmake file elsewhere in the project, where the ${PROJECT_NAME} was defined - so as to add a dependency:
ADD_DEPENDENCIES(${PROJECT_NAME} scintilla.a)
... and finally, the library needs to be linked.
Note that in the commands heretofore, the scintilla.a is merely a name/label/identifier/string (so it could be anything else, like scintilla--a or something); but for linking - the full path to the actual `scintilla.a file is needed (which in this project ends up in a variable ${SCINTILLA_LIBRARY}). In this project, the linking basically occurs through a form of a
list(APPEND PROJ_LIBRARIES ${SCINTILLA_LIBRARY} )
... and I don't really know how cmake handles the actual linking afterwards (but it seems to work)
For consistency, I tried to use ${SCINTILLA_LIBRARY} instead of scintilla.a as identifier in the ADD_CUSTOM_TARGET, but got error: "Target names may not contain a slash. Use ADD_CUSTOM_COMMAND to generate files". So probably this could be solved smarter/more correct with ADD_CUSTOM_COMMAND - however, I read that it "defines a new command that can be executed during the build process. The outputs named should be listed as source files in the target for which they are to be generated."... And by now I'm totally confused so as to what is a file, what is a label, and what is a target - so I think I'll leave at this (and not fix it if it ain't broken :) )
Well, it'd still be nice to know a more correct way to do this eventually,
Cheers!