Re: [CMake] How to set CTEST_BUILD_NAME
Hi Donald,
For my project, I do it this way.
In my CMakeLists.txt, I first set the variable BUILDNAME in cache
before calling `include(CTest)`.
# define BUILDNAME, used to submit jobs to CDash
set(BUILDNAME "Whatever you want" CACHE STRING "" FORCE)
# This must be called after SITE and BUILDNAME variables are set
include(CTest)
I hope this will work for you.
Best regards,
Xavier
On Sun, Dec 16, 2018 at 9:22 PM Craig Scott wrote:
>
>
> On Mon, Dec 17, 2018 at 6:41 AM Donald MacQueen [|] <
> dm...@instantiations.com> wrote:
>
>> I want to do something like set(CTEST_BUILD_NAME
>> {CMAKE_SYSTEM_NAME}_someLocalVariable)
>>
>> I tried putting this ^^ in CTestConfig.cmake with no luck.
>>
>> I searched the docs and the archives from 2014 to the present and
>> nothing jumped out at me.
>>
>> 2) Is there a list of what can be set/used in CTestConfig.cmake?
>>
>
> The variables are not all collected together conveniently, but the Dashboard
> Client section
> <https://cmake.org/cmake/help/latest/manual/ctest.1.html#dashboard-client-configuration>
> of the ctest command does list the supported variables associated with each
> command. It would seem like setting CTEST_BUILD_NAME should work based on
> those docs, so perhaps if you could point us as a minimal complete example
> which demonstrates your problem, that might give more clues as to what's
> happening for you.
>
>
> --
> Craig Scott
> Melbourne, Australia
> https://crascit.com
>
> New book released: Professional CMake: A Practical Guide
> <https://crascit.com/professional-cmake/>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake
>
>
> -------
>
> This e-mail can not be trusted due to SPF/DKIM validation failed.
>
>
> ---
>
>
--
Dr Xavier BESSERON
Research Scientist
FSTC, University of Luxembourg
Campus Belval, Office MNO E04 0415-040
Phone: +352 46 66 44 5418
http://luxdem.uni.lu/team/xbesseron/
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake equivalent to Boost.Build site-config.jam oruser-config.jam
Hi all,
>From my understanding, the toolchain files are only inteneded for
cross-compilation and I'm afraid you will run in some kind of troubles if
you try to use it for something else.
As far I know, this feature you describe does not exist in CMake.
However I have a piece of CMake code that does what you want. Please find
it below. Maybe this can help you.
- By default, it loads the settings from file Local_Settings.cmake. It is
ignored silently if it does not exist
- You can use -DLOCAL_SETTINGS=My_Other_Local_Settings.cmake on the CMake
command line to specify a different file
In a separate file Load_Local_Settings.cmake:
# Default name for Local Settings file
set(DEFAULT_LOCAL_SETTINGS_FILE "${CMAKE_SOURCE_DIR}/Local_Settings.cmake")
# CMake cache option
set(LOCAL_SETTINGS "" CACHE FILEPATH "Path to a file containing Local
Settings to load")
# Set LOCAL_SETTINGS_FILE variable
if(LOCAL_SETTINGS)
# If cache variable is set, use it and fails if it is not valid
if(EXISTS "${LOCAL_SETTINGS}" AND NOT IS_DIRECTORY "${LOCAL_SETTINGS}")
set(LOCAL_SETTINGS_FILE "${LOCAL_SETTINGS}")
else()
message(FATAL_ERROR "'${LOCAL_SETTINGS}' is not a valid file for
LOCAL_SETTINGS")
endif()
else()
# Otherwise, try default filename, and ignore silently if it does not exist
if(EXISTS "${DEFAULT_LOCAL_SETTINGS_FILE}" AND NOT IS_DIRECTORY
"${DEFAULT_LOCAL_SETTINGS_FILE}")
set(LOCAL_SETTINGS_FILE "${DEFAULT_LOCAL_SETTINGS_FILE}")
else()
set(LOCAL_SETTINGS_FILE "")
endif()
endif()
# Load the settings from the file if variable is defined
if(LOCAL_SETTINGS_FILE)
message(STATUS "Using Local Settings from '${LOCAL_SETTINGS_FILE}'")
include("${LOCAL_SETTINGS_FILE}")
endif()
Then, in your main CMakeLists.txt, just add:
# Load Local Settings
include( Load_Local_Settings.cmake )
For example, in my Local_Settings.cmake file, I put things like:
set(EIGEN3_ROOT "/path/to/eigen/install" CACHE STRING "")
# You can use environment variables too
set(BOOST_ROOT "$ENV{EBROOTBOOST}" CACHE STRING "")
I hope this helps.
Best regards,
Xavier
On Tue, Aug 8, 2017 at 9:31 PM, Lectem wrote:
> I think that you are looking for the toolchain files :
>
> https://cmake.org/cmake/help/v3.0/manual/cmake-toolchains.7.html
>
>
>
> The other option is to use a cmake script to specify your variables which
> includes CMakelists.txt (or the other way around if you can modify the
> CMakelists.txt). This would be quite similar to ctests scripts.
>
> Some good examples are in Daniel Pfeifer’s « Effective cmake » talk
> https://github.com/boostcon/cppnow_presentations_2017/blob/
> master/05-19-2017_friday/effective_cmake__daniel_pfeifer__
> cppnow_05-19-2017.pdf
>
>
>
>
>
> *De : *Brian Davis
> *Envoyé le :*mardi 8 août 2017 20:09
> *À : *cmake Mailing List
> *Objet :*[CMake] CMake equivalent to Boost.Build site-config.jam
> oruser-config.jam
>
>
>
>
> Is there a CMake equivalent to a site-config.jam or user-config.jam
>
> http://www.boost.org/build/doc/html/bbv2/recipies/site-config.html
>
> basically a CMake file the user can put in a project directory that CMake
> will read first when using cmake-gui that allows user to specify stuff they
> don't want to have to keep specifying in cmake-gui each "delete cache"
>
> such as
>
> set( CMAKE_INSTALL_PREFIX ${CURRENT_LIST_DIR}/install CACHE STRING ""
> FORCE)
> set( CMAKE_DEBUG_POSTFIX d CACHE STRING "" FORCE )
>
> There is cmake.exe
>
>
>
> -C
>
> but requires command line
>
> come to think of it would be nice if
>
> set( CMAKE_GENERATOR_PLATFORM "Visual Studio 12 2013 Win64" )
>
> in desired user config file and CMake would just "make it so" on clicking
> Generate.
>
> I can do this with my own projects, by implementing it myself, but when
> checking out 3rd party projs they can be all over the map on config
> allowing a user-config.cmake would provide mechanism to tame the config
> problems.
>
> Desired workflow
>
> 1) Checkout 3rd party proj
>
> 2) put a CMakeUser.txt or whatever file per project
>
> 3) Run CMake GUI Generate
>
> 4) Click Open Project
>
> 5) Change whatever manual bits in in gui
>
> 6) Update project suing git witch branches versions
>
> 7) Delete Cache
>
> 8) Return to 3
>
> 9) Doopy doopy doo whatever else
>
>
>
>
>
>
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers
Re: [CMake] Get ctest -S script to pull from git branch other than 'master'?
Hi Ross,
Here is how I do it in my case:
...
# Initial checkout if no source directory
if(NOT EXISTS "${CTEST_SOURCE_DIRECTORY}")
message("Initial checkout...")
set(CTEST_CHECKOUT_COMMAND "git clone --branch ${GIT_BRANCH}
${REPOSITORY} ${SOURCE_DIR_NAME}")
endif()
# Initialize testing
message("Initialize ${CTEST_MODEL} testing...")
ctest_start(${CTEST_MODEL} TRACK "${CTEST_SUBMISSION_TRACK}")
message("Update source...")
set(CTEST_GIT_COMMAND "git")
ctest_update(RETURN_VALUE NB_CHANGED_FILES)
message("Found ${NB_CHANGED_FILES} changed file(s)")
...
I hope this helps.
Best regards,
Xavier
On Tue, Jun 7, 2016 at 11:04 PM, Bartlett, Roscoe A
wrote:
> Hello,
>
>
>
> Is there a built-in way to get a ctest -S script to checkout and pull from
> a git branch other than ‘master’? I can’t seem to find a way to so this
> and there is no mention of branches at all in the official documentation:
>
>
>
>
> https://cmake.org/cmake/help/v3.6/command/ctest_update.html?highlight=ctest_update
>
>
>
> and there is no mention of “branch” at:
>
>
>
> https://cmake.org/Wiki/CMake/Testing_With_CTest
>
>
>
> Currently, I see code that people have written which is explicitly
> checking out and updating the desired branch after ctest_update() is called
> (e.g. this what TribitsCTestDriverCore.cmake does). Therefore, this CTest
> code is really just using ctest_update() to do a `git fetch` on the
> external repo. In this case, if the local branch is changed to a tracking
> branch, then will ctest_update() leave that tracking branch as is and just
> pull from the tracking branch the next time the ctest –S script is called?
> If that is the case, then I would expect CTest to report the correct list
> of “updated files”. But if ctest_update() instead switches back to the
> ‘master’ branch and then does the pull, then it will likely report the
> wrong list of “updated files”.
>
>
>
> I can dig into the source code for CTest to see what it actually does but
> it would be nice to have direct support for choosing the branch or at the
> very least just documenting the current behavior and describe the best way
> to work around the issue.
>
>
>
> Thanks,
>
>
>
> -Ross
>
>
>
>
>
> Dr. Roscoe A. Bartlett, PhD
>
> Sandia National Laboratories
>
> Trilinos Software Engineering and Integration Technologies Lead
>
> Consortium for the Advanced Simulation of Light Water Reactors (CASL)
> Physics Integration Infrastructure Lead
>
>
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake
>
--
Dr Xavier BESSERON
Research associate
FSTC, University of Luxembourg
Campus Kirchberg, Office E-007
Phone: +352 46 66 44 5418
http://luxdem.uni.lu/
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] How to suppress valgrind errors reported by NightlyMemCheck ?
Hi Aaron, I don't know if that's what you're looking for, but you can try to set Valgrind options using an environment variable or a cmake variable set(VALGRIND_OPTS "--suppressions=/path/to/your_suppression_file.supp") or export VALGRIND_OPTS="--suppressions=/path/to/your_suppression_file.supp" Best regards, Xavier On Sun, Mar 20, 2016 at 6:14 PM, Aaron Boxer wrote: > My program links to libstdc++. It turns out there is a well-known false > positive > from valgrind regarding libstdc++ memory pools. > > http://valgrind.org/docs/manual/faq.html#faq.reports > > How may I suppress this error when running ctest -D NightlyMemCheck ? > > Thanks, > Aaron > -- Dr Xavier BESSERON Research associate FSTC, University of Luxembourg Campus Kirchberg, Office E-007 Phone: +352 46 66 44 5418 http://luxdem.uni.lu/ -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] how to keep rpath from build to install
Srinath, You should better ask the list than me. It would help if you describe precisely what you tried, and what result you get. Best regards, Xavier On Tue, Mar 8, 2016 at 4:31 PM, Srinath Vadlamani < srinath.vadlam...@gmail.com> wrote: > Hello Xavier, > I have implemented all of what is in the website and if I objdump -x * | > grep -i rpath on the executables in the install directory I get a null > result. > > Thanks, > <>Srinath > > = > Srinath Vadlamani > ===== > > On Mon, Mar 7, 2016 at 2:14 PM, Xavier Besseron > wrote: > >> Hi Srinath, >> >> I guess you will find what you need here: >> https://cmake.org/Wiki/CMake_RPATH_handling >> >> Best regards, >> >> Xavier >> >> >> On Mon, Mar 7, 2016 at 4:35 PM, Srinath Vadlamani < >> srinath.vadlam...@gmail.com> wrote: >> >>> Hello All, >>> How do I keep the rpath used during the build of an executable the >>> same when I install that executable using INSTALL(TARGETS )? >>> >>> I do set : >>> >>> SET(CMAKE_INSTALL_RPATH_USE_LINK_PATH TRUE) >>> >>> = >>> Srinath Vadlamani >>> ===== >>> >> >> >> >> -- >> Dr Xavier BESSERON >> Research associate >> FSTC, University of Luxembourg >> Campus Kirchberg, Office E-007 >> Phone: +352 46 66 44 5418 >> http://luxdem.uni.lu/ >> >> > -- Dr Xavier BESSERON Research associate FSTC, University of Luxembourg Campus Kirchberg, Office E-007 Phone: +352 46 66 44 5418 http://luxdem.uni.lu/ -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] Support OpenBLAS in FindBLAS module
Hi all, Is there any update on this issue? I believe this addition would be really useful. Best regards, Xavier On Sat, Nov 29, 2014 at 4:12 AM, Rob Zumwalt wrote: > Apologies for the new thread, I just subscribed in order to comment on > this, and didnt know how to reply in the existing thread. > > I am grateful to Xianyi for his addition of OpenBlasConfig.cmake, and I > do recognize that this is the direction that projects should go when > wanting to build CMake support for their users. The issue, as cgorac points > out, is that other projects (LAPACK in this case) use FindBLAS.cmake inside > their FindLAPACK.cmake files. So, in order to get FindLAPACK.cmake to work > with OpenBLAS, it would require that the developers that maintain > FindLAPACK.cmake change that file. The same would have to happen for any > other projects that use FindBLAS.cmake. > > In short, CMake already has a “blessed” set of BLAS implementations (MKL, > Intel, Goto, etc.), and it would be easier for users of LAPACK (and users > of projects that use BLAS), if OpenBLAS were included in this set of CMake > “blessed” BLAS implementations. Of course, OpenBLAS would still be happy to > provide OpenBlasConfig.cmake (I am guessing) for users of OpenBLAS directly. > > Best Regards, > Rob > -- Dr Xavier BESSERON Research associate FSTC, University of Luxembourg Campus Kirchberg, Office E-007 Phone: +352 46 66 44 5418 http://luxdem.uni.lu/ -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] how to keep rpath from build to install
Hi Srinath, I guess you will find what you need here: https://cmake.org/Wiki/CMake_RPATH_handling Best regards, Xavier On Mon, Mar 7, 2016 at 4:35 PM, Srinath Vadlamani < srinath.vadlam...@gmail.com> wrote: > Hello All, > How do I keep the rpath used during the build of an executable the same > when I install that executable using INSTALL(TARGETS )? > > I do set : > > SET(CMAKE_INSTALL_RPATH_USE_LINK_PATH TRUE) > > = > Srinath Vadlamani > ========= > -- Dr Xavier BESSERON Research associate FSTC, University of Luxembourg Campus Kirchberg, Office E-007 Phone: +352 46 66 44 5418 http://luxdem.uni.lu/ -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] How to pass a configuration file to CMake?
Hi Cedric, I believe you should do it this way: Your config.cmake file should be: set(ENABLE_DOWNLOAD True CACHE BOOL "") set(GCC_ROOT "/local/cdoucet/gcc/4.9.2/" CACHE PATH "") In the signature of set() for "Set Cache Entry", the *docstring* is mandatory. cf https://cmake.org/cmake/help/v3.4/command/set.html#set-cache-entry And you forgot the path to your source directory in your CMake command line : cmake -C ../config.cmake /path/to/your/source I hope this helps! Xavier On Thu, Jan 21, 2016 at 3:43 PM, Cedric Doucet wrote: > > > Hello, > > I do not manage to pass a configuration file to cmake. > > I type 'cmake -C ../config.cmake' > > where config.cmake belongs to the parent directory and contains these > lines: > > set(ENABLE_DOWNLOAD True CACHE BOOL) > set(GCC_ROOT "/local/cdoucet/gcc/4.9.2/" CACHE PATH) > > I get the following error message but I don't understand why: > > loading initial cache file ../config.cmake > CMake Error at /local/cdoucet/simol/config.cmake:1 (set): > set given invalid arguments for CACHE mode. > > > CMake Error at /local/cdoucet/simol/config.cmake:2 (set): > set given invalid arguments for CACHE mode. > > > CMake Error: The source directory "/local/cdoucet/simol/config.cmake" is a > file, not a directory. > > > Do you know how to solve this problem? > > - Cedric Doucet a écrit : > > > > Hi Peter! > > Thank you very much! > It seems to be exactly what I want. :) > I will try to use it. > > Cédric > > -- > > *De: *"Petr Kmoch" > *À: *"Cedric Doucet" > *Cc: *cmake@cmake.org > *Envoyé: *Lundi 21 Décembre 2015 13:25:53 > *Objet: *Re: [CMake] How to pass a configuration file to CMake? > > Hi Cedric. > > I have never used it myself, but I believe you're looking for CMake's > command-line option '-C ': > https://cmake.org/cmake/help/latest/manual/cmake.1.html > > Petr > > On Mon, Dec 21, 2015 at 1:12 PM, Cedric Doucet > wrote: > >> >> Hello, >> >> I would like to know if it's possible to pass a configuration file to >> CMake. >> I have to pass a lot of information to CMake and the resulting command >> line is very long to type. >> Would it be possible to create a file containing all needed definitions >> and pass it to CMake? >> >> For exemple, instead of typing >> >> cmake -D CMAKE_BUILD_TYPE=Debug -D CMAKE_INSTALL_PREFIX=/home/me/there -D >> CMAKE_CXX_COMPILER=/usr/local/gcc/4.9.3/g++ >> >> would it be possible to create a file containing >> >> CMAKE_BUILD_TYPE=Debug >> CMAKE_INSTALL_PREFIX=/home/me/there >> CMAKE_CXX_COMPILER=/usr/local/gcc/4.9.3/g++ >> >> and pass it to CMake? >> >> Cédric >> >> -- >> >> > >> >> > Powered by www.kitware.com >> >> > >> >> > Please keep messages on-topic and check the CMake FAQ at: >> http://www.cmake.org/Wiki/CMake_FAQ >> >> > >> >> > Kitware offers various services to support the CMake community. For >> more information on each offering, please visit: >> >> > >> >> > CMake Support: http://cmake.org/cmake/help/support.html >> >> > CMake Consulting: http://cmake.org/cmake/help/consulting.html >> >> > CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> > >> >> > Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> > >> >> > Follow this link to subscribe/unsubscribe: >> >> >http://public.kitware.com/mailman/listinfo/cmake >> > > > > > > > > -- Dr Xavier BESSERON Research associate FSTC, University of Luxembourg Campus Kirchberg, Office E-007 Phone: +352 46 66 44 5418 http://luxdem.uni.lu/ -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] TARGET_LINK_LIBRARIES with full path libraries
Dear all, I had the same issue some time ago with the Boost library. The solution for me was to declare this library as "imported". Here is an example: add_library( curl UNKNOWN IMPORTED) set_property(TARGET curl PROPERTY IMPORTED_LOCATION "/opt/XXX/lib/libcurl.so.4") add_executable(xxx xxx.cpp) target_link_libraries(xxx curl) Here are some relevant links: http://www.cmake.org/pipermail/cmake/2011-June/044790.html http://www.cmake.org/Wiki/CMake_2.6_Notes#Linking_to_System_Libraries Regards, Xavier 2014-09-18 9:05 GMT+02:00 J Decker : > It shouldn't truncate paths if specified... cause of course if we want to > test against a dev version then maybe the script knows better. But neither > should it add the full path if it's not specified in the script. > > On Wed, Sep 17, 2014 at 11:59 PM, Nils Gladitz > wrote: >> >> On 09/18/2014 07:52 AM, Volker Pilipp wrote: >>> >>> That actually does the trick. But it's not nice, because there are many >>> targets in the project. >>> Actually, I do not know about any use case, where cmake should replace a >>> full path to a lib >>> by its "-l" shortcut. >> >> >> There are as far as I understand two use cases. >> >> - The library does not have a SONAME >> Linking to the library by path would embed the full path of the library >> in the target rather than just the name (which is what it does with -l or >> when the library does have a SONAME set) >> >> - The second use case I am not familiar with myself but the explanation in >> the code is: >> // Many system linkers support multiple architectures by >> // automatically selecting the implicit linker search path for the >> // current architecture. If the library appears in an implicit link >> // directory then just report the file name without the directory >> // portion. This will allow the system linker to locate the proper >> // library for the architecture at link time. >> >> >> Nils >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: >> http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For more >> information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/cmake > > -- Dr Xavier BESSERON Research associate FSTC, University of Luxembourg Campus Kirchberg, Office E-007 Phone: +352 46 66 44 5418 http://luxdem.uni.lu/ -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] Need cmake to work on AIX 5.3
Hi Arindam, Maybe you can try this way: http://www.cmake.org/Wiki/CMake_FAQ#How_do_I_use_a_different_compiler.3F Xavier On Tue, Oct 9, 2012 at 11:58 AM, Arindam Mukherjee < arindam.muker...@gmail.com> wrote: > Hi, > > I have to get a build of my product on AIX 5.3 (powerpc) because of > backward compatibility concerns. The product builds fine on such a > system using conventional gmake. However, cmake fails to identify the > xlc/xlC compilers correctly and reports them as broken. What is the > way to fix this? > > Could I force cmake to recognize the compilers correctly in some > manual way. I tried using CMAKE_FORCE_C_COMPILER and > CMAKE_FORCE_CXX_COMPILER but it didn't work. I am not sure of the > arguments to pass either. Any help is greatly appreciated. > > Thanks, > Arindam > -- > > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Follow this link to subscribe/unsubscribe: > http://www.cmake.org/mailman/listinfo/cmake > -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Cross compiling for Windows x64/amd64 on 32-bit Windows
On Tue, Oct 2, 2012 at 1:09 PM, Arindam Mukherjee wrote: > On Tue, Oct 2, 2012 at 4:22 PM, David Cole wrote: >> >> >> cmake -G "Visual Studio 9 2008 Win32" src_dir >> >> will not work. There is no such generator. Leave out the " Win32" for this >> case... it is implied. >> >> > > How would it be on a Windows x64 box? I don't have access to one. > Would "Visual Studio 9 2008" still mean 32-bit on it? > Yes. VS9 Win32 generator is still called "Visual Studio 9 2008" on a 64-bit Windows. Xavier -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Cross compiling for Windows x64/amd64 on 32-bit Windows
Hi, I was able to build win64 executable on my 32-bit Windows. First, I had to make the "full installation" of VS 2008 (the "default installation" did not provide the win64 compiler in my case). Then, I had to select the "Visual Studio 9 2008 Win64" generator in CMake. And the project built correctly. However, it is not possible to execute the generated binaries on a 32-bit Windows. Xavier On Mon, Oct 1, 2012 at 10:45 PM, John Drescher wrote: > On Mon, Oct 1, 2012 at 4:35 PM, Arindam Mukherjee > wrote: >> Hi, >> >> I have a Windows XP build setup with Visual Studio 2008 SP1 and >> Windows SDK 6. I have set up a CMake project for a source base that is >> built on Linux, Solaris, AIX and Windows. So far I have managed to get >> the Windows 32-bit build going but cannot make the x64 cross-compile >> work. >> >> It seems that CMake generates 32-bit builds even when I initialize the >> 64-bit build system (vcvarsall.bat x64). What is the correct way to >> set such a build up. >> > > I do not believe Visual Studio will build x64 targets on 32 bit > windows. The first issue would be installing the x64 compiler. However > I could be wrong. > > John > -- > > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Follow this link to subscribe/unsubscribe: > http://www.cmake.org/mailman/listinfo/cmake -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Bug fix requests for the *next* release of CMake...
Sorry for this late reply. http://public.kitware.com/Bug/view.php?id=12630 - "Support for SVN externals in CTest update" I will resume the discussion about this issue in the mailing list. Xavier On Fri, Aug 10, 2012 at 10:47 PM, David Cole wrote: > Hi all, > > Replies requested. Short replies only. Read on. Just a short reply > with bug numbers or links to the bugs is all we need here. > > Example one-line reply: > > http://public.kitware.com/Bug/view.php?id=13463 > > Please move specific discussions into the bugs themselves or start a > new thread to talk about it... Replies on this thread should just be a > collector for bug numbers. > > We are aiming for approximately quarterly releases from now on, > scheduling them every 3 to 4 months. The next release of CMake will > likely be version 2.8.10, scheduled to have an "rc1" release candidate > on Wed. October 17, 2012 -- just 9 weeks from next Wednesday. > > If you have a particular issue that you think should be fixed for > inclusion in 2.8.10, please bring it up within the next two weeks. > Ideally, each issue will be discussed as needed on the mailing list to > come to any consensus about what should be done to fix it, and then an > entry in the bug tracker may be used to keep it on the radar screen, > and to track activity related to it. You can see what's on the roadmap > for this release here: > http://public.kitware.com/Bug/roadmap_page.php?version_id=100 > > Patches are always welcome. Patches that include testing of any new > features, or tests that prove a bug is really fixed on the dashboards, > (basically any patch with testing) is preferred over a patch with no > testing. Also, if you are *adding* code, then you also probably need > to add *tests* of that code, so that the coverage percentage stays as > is or rises. > > Please discuss issues here as needed, and add notes to existing issues > in the bug tracker that you are interested in seeing fixed -- we will > be looking at the mailing list and activity in the bug tracker to help > prioritize the bug fixes that will occur in the near future. > > > Thanks, > David Cole > Kitware, Inc. > > > P.S. - as a nice summary of what we accomplished in the CMake 2.8.9 > release, see here: > http://public.kitware.com/Bug/changelog_page.php?version_id=93 -- it > currently lists 74 issues that we resolved: nice job, everybody! > > (Many of those were specifically addressed because somebody asked for > it right here on the mailing list... Don't be shy!) > -- > > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Follow this link to subscribe/unsubscribe: > http://www.cmake.org/mailman/listinfo/cmake -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Recommended Multilib Build Approach?
On Mon, Jul 30, 2012 at 9:44 PM, Alexander Neundorf wrote: > On Monday 30 July 2012, Xavier Besseron wrote: >> To build i386 binaries on my 64-bit system with multilib, I just do >> something like this: >> >> mkdir build-i386 >> cd build-i386 >> CFLAGS="-m32" CXXFLAGS="-m32" LDFLAGS="-melf_i386" cmake ../src/ >> >> And to build x86-64 binaries on my 64-bit system, I don't need to >> specify anything since it is the default behavior. > > Is this maybe somewhat similar to the fat binaries on OSX ? No, I don't think so. You have to use two build directories, one for 32-bit code, one for 64-bit code. At the end, you will have two different binaries. > How is this handled by CMake ? This is quite independent of CMake. It works with other build systems like autotools/makefile as well. CFLAGS="-m32" CXXFLAGS="-m32" tells CMake to pass the '-m32' to the C and C++ compilers. It tells the compiler to generate code that runs on any i386 system (cf gcc manpage). LDFLAGS="-melf_i386" tells CMake to pass the '-melf_i386' to the linker. It tells the linker to use the i386 ELF format for the binary (cf ld manpage). This works for GNU compiler/linker at least. I haven't tried other compilers. Xavier -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Recommended Multilib Build Approach?
Hello Greg, To build i386 binaries on my 64-bit system with multilib, I just do something like this: mkdir build-i386 cd build-i386 CFLAGS="-m32" CXXFLAGS="-m32" LDFLAGS="-melf_i386" cmake ../src/ And to build x86-64 binaries on my 64-bit system, I don't need to specify anything since it is the default behavior. Xavier On Mon, Jul 30, 2012 at 6:43 PM, Gregory Peele ARA/CFD wrote: > From: Alexander Neundorf [mailto:a.neundorf-w...@gmx.net] > Sent: Saturday, July 28, 2012 11:48 AM > To: cmake@cmake.org > Cc: Gregory Peele ARA/CFD > Subject: Re: [CMake] Recommended Multilib Build Approach? > > On Thursday 21 June 2012, Gregory Peele ARA/CFD wrote: >>> Hi all, >>> >>> I want to be able to build 32-bit and 64-bit from the same GCC multilib >>> install (currently for MinGW-w64, though this also applies for Linux/Mac >>> GCC and LLVM). To clarify, I want to be able to do two completely >>> separate builds in separate binary dirs - building fat binaries from >>> multiple architectures in the same binary dir is a separate problem I'm >>> also interested in for Android, but I'm not worrying about that yet. >>> >>> What is the "proper" approach to building the non-default arch in a >>> multilib setup? Obviously using CMake as-is will build the default arch >>> just fine. >> I think there are no recommendations yet. I'm not aware that somebody else >> already tried to do this. >> Can the executables built for the non-default architecture be executed on >> the hopst where you are building ? >> If so, there should be a way :-) >> If not, this sounds like somewhat like crosscompiling. >> Alex > > I haven't explored the topic any further since posting. On a multilib > system, all multilib architectures are "native" to the host and can be > executed. Basically the problem I wanted to solve was getting the x86-64 GCC > or LLVM compiler to produce 32-bit x86 code in an easy and non-intrusive way. > > Right now I'm forcibly adding the "-m32" flags to all relevant CMake > variables within my top-level CMake script if CMAKE_SYSTEM_PROCESSOR is set > to x86 or i686, and conversely the "-m64" flags if set to x86-64 or AMD64. > It seems like there should be a less intrusive way of doing it, and I'm not > sure if this skews some early compiler/platform tests prior to me overriding > the flags. Visual Studio doesn't have this issue since the 32-bit and 64-bit > builds are entirely separate CMake generators - a strange decision, in my > opinion, but easy enough to work with. > > Greg > -- > > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Follow this link to subscribe/unsubscribe: > http://www.cmake.org/mailman/listinfo/cmake -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
