[CMake] Using a custom preprocessor
Hi! I am currently working on a project which uses plain old make as a build system. Needless to say, adding new compilers etc. is a lot of work, so I would like to start using CMake, which I have had excellent experience with in the past. There is one peculiarity that I do not know how to handle. Some of our code (C and Fortran) is contained in files that end with .cs or .fs, which are run through an in-house preprocessor. A Makefile target is then something along the lines of (but not exactly) foo.o: foo.f $(FC) -c $(FFLAGS) foo.f foo.f: foo.fs custom_preproc foo.fs -o foo.f Is it possible to, somehow, add this pre-compilation step for such files, and then add_executable(myexe foo.fs bar.cs main.f90) ? Cheers, Paul -- 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
[CMake] Viewing the full build log from the CDash Dashboard
Apologies if this is a stupid question with an obvious answer staring me in the face but... How does one view the full build log from the dashboard? This relates to our own dashboard but looking at a build of CMake as an example (http://open.cdash.org/buildSummary.php?buildid=3450103) The full output of the configure step seems to be displayed on the buildSummary page but there's nothing for the actual build (gmake in this case) step. CDash will show a cut-down summary of where it thinks the errors or warnings are but sometimes (especially with parallel builds) these are wrong (or false positives) or alternatively everything succeeded but you still want to browse through the build output. Our current build system captures the output of the ctest process and emails it separately but surely this must be available through CDash? Thanks Matt -- 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] Windows RC files with Ninja
I found a workaround. Turns out that the issue is caused when not enabling C language support in the project() command. i.e I was doing cmake_minimum_required( VERSION 3.0.0 ) project( proj CXX) Changing this to cmake_minimum_required( VERSION 3.0.0 ) project( proj CXX) fixes the issue. http://public.kitware.com/Bug/view.php?id=15088 Frank > -Original Message- > From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Miller, > Frank > Sent: Tuesday, August 12, 2014 11:44 AM > To: CMake MailingList > Subject: [CMake] Windows RC files with Ninja > > Greetings, > > I tried to move from 2.8 to 3.0.1 today and I'm experiencing an issue with RC > files. Looks like a simple problem but I would be baffled if I'm the first to > experience this so I expect I have some kind of configuration issue. Here is > the offending snippet in the rules.ninja file: > > rule RC_COMPILER > depfile = $DEP_FILE > deps = gcc > command = "" RC $in "$DEP_FILE" $out "" "c:/Program Files (x86)/Microsoft > Visual Studio 12.0/VC/bin/cl.exe" > c:\PROGRA~2\WI3CF2~1\8.1\bin\x86\rc.exe $FLAGS $DEFINES /fo$out $in > description = Building RC object $out > > If I put the path to "cmcldeps.exe" in the empty quotes on the command > line, it works as expected. > > Does anyone else have this problem? > > Frank > > This communication, including any attachments, may contain information > that is proprietary, privileged, confidential or legally exempt from > disclosure. > If you are not a named addressee, you are hereby notified that you are not > authorized to read, print, retain a copy of or disseminate any portion of this > communication without the consent of the sender and that doing so may be > unlawful. If you have received this communication in error, please > immediately notify the sender via return e-mail and delete it from your > system. In order to safeguard its employee data as well as sensitive patient, > customer, business, legal and other information, the company uses all lawful > means, under all applicable law, to access, monitor, preserve, collect and > review all communications between employees and all other users only > when, and to the extent necessary, to fulfill investigatory and other > important business and legal responsibilities. By responding to this > communication, or initiating additional co > mmunication with the company, you consent to such lawful monitoring, to > the extent such consent is required and valid in your local area. > -- > > 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 This communication, including any attachments, may contain information that is proprietary, privileged, confidential or legally exempt from disclosure. If you are not a named addressee, you are hereby notified that you are not authorized to read, print, retain a copy of or disseminate any portion of this communication without the consent of the sender and that doing so may be unlawful. If you have received this communication in error, please immediately notify the sender via return e-mail and delete it from your system. In order to safeguard its employee data as well as sensitive patient, customer, business, legal and other information, the company uses all lawful means, under all applicable law, to access, monitor, preserve, collect and review all communications between employees and all other users only when, and to the extent necessary, to fulfill investigatory and other important business and legal responsibilities. By responding to this communication, or initiating additional co mmunication with the company, you consent to such lawful monitoring, to the extent such consent is required and valid in your local area. -- 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] Resetting CMAKE_Fortran_FLAGS for a specific file
In my opinion this is a deficiency in how cmake currently works with object
libraries. If one of the source files in an object library depends on a
third library then it should be possible to specify that in the link
interface of either the object library or the source file. It is wrong to
have to specify the dependency multiple times for every library or
executable that uses the object library. It is a property of the object
library, not the users of the object library.
I believe there is already a enhancement request open for something like
this.
--
Glenn
On 13 August 2014 15:44, marco restelli wrote:
> 2014-08-13 16:16 GMT+0200, Mark Abraham :
> > On Wed, Aug 13, 2014 at 7:12 AM, marco restelli
> > wrote:
> >
> >> 2014-08-13 15:53 GMT+0200, Mark Abraham :
> >> > On Wed, Aug 13, 2014 at 3:18 AM, marco restelli
> >> > wrote:
> >> >
> >> >> Hi Petr,
> >> >>thanks, very informative!
> >> >>
> >> >> 2014-08-13 9:20 GMT+0200, Petr Kmoch :
> >> >> > Hi Marco.
> >> >> >
> >> >> > Sane compilers allow later command-line options to override earlier
> >> >> > ones,
> >> >> > so what you're doing should be fine. Unfortunately, I know some
> >> Fortran
> >> >> > compilers are not sane in this regard.
> >> >>
> >> >> Here, I would really like to reduce as much as possible the flags
> >> >> regardless of the chosen compiler, so "undoing" the chosen flags
> >> >> seems to me cumbersome and compiler dependent, compared to resetting
> >> >> them altogether. I like the idea of OBJECT libraries better (it also
> >> >> solves other problems I have, I did not know about it!).
> >> >>
> >> >> > If you really need to solve this by explicitly modifying the global
> >> >> > list
> >> >> > for a particular file, the only thing I can think of is move those
> >> >> > files
> >> >> to
> >> >> > a separate CMakeList and turn them into an object library:
> >> >>
> >> >> This almost works, I have a problem specifying liking dependencies
> for
> >> >> the OBJECT libraries. With a normal library, I can use
> >> >>
> >> >> TARGET_LINK_LIBRARIES( my_library ${other_libs_my_library_depends_on}
> >> >> )
> >> >>
> >> >> but if my_library is OBJECT I see the error
> >> >>
> >> >> Object library target "my_library" may not link to anything.
> >> >>
> >> >
> >> > See http://www.cmake.org/cmake/help/v3.0/command/add_library.html for
> >> the
> >> > correct way to do things with object libraries - for this purpose,
> they
> >> are
> >> > closer to source files than libraries, which makes sense given that
> >> there's
> >> > not actually a library written to disk anywhere.
> >>
> >> Mark, thanks, but here I don't find anything that answers my question,
> >> namely specifying that my OBJECT library (i.e. the files included in
> >> it) require other libraries for linking.
> >
> >
> > The object library is never linked, so the issue of linking with it or to
> > it does not arise. The targets that use the object library have
> transitive
> > linking dependencies, just like you had if the source files in the object
> > library had been directly specified as part of those targets.
>
> OK, let me see if I understad it. Using the example in
>
> http://www.cmake.org/Wiki/CMake/Tutorials/Object_Library
>
> let us say I have
>
>
> # A/CMakeLists.txt
> add_library(A OBJECT ${A_srcs})
>
> # B/CMakeLists.txt
> add_library(B OBJECT ${B_srcs})
>
> # CMakeLists.txt
> add_subdirectory(A)
> add_subdirectory(B)
> add_library(big ${other_srcs} $ $)
>
>
> and I know that whenever I link the files listed in ${A_srcs}, i.e.
> whenever I likd the OBJECT library A, I also need to link
> libsomeotherlibrary.a . Then in the main CMakeLists.txt I add
>
> TARGET_LINK_LIBRARIES( big someotherlibrary )
>
> right?
>
>
> Moreover, there is no way to specify someotherlibrary in
> A/CMakeLists.txt, it has to be done where I define the target big,
> namely in the main CMakeLists.txt. Is this correct?
>
>
> Thanks,
>Marco
> --
>
> 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
>
--
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/cma
Re: [CMake] Generator-independent incremental CMake run
On 8/14/2014 11:26 AM, Nagger wrote:
So ZERO_CHECK is 34 times faster. Why shouldn't I take advantage of that.
If CMake does not need to re-run, then ZERO_CHECK will always be faster
than cmake build_dir. cmake build_dir will run a full configure and
generate no matter what. That said, a cmake --build all, should do the
same thing. Going back to your original question:
For our Continuous Integration tests we need fast incremental builds (only
build what has changed).
This also includes that CMake only has to run if necessary (some CMakeLists.txt
changed).
It seems there is no beautiful/portable/generator-independent way to do this?!
The way to do this is to use a ctest script. You can basically do all
the stuff in your batch script. It would be something like this:
if(NOT EXISTS ${BULD_TREE)
do_configure_and_build()
endif()
function(do_configure_and_build)
ctest_update()
ctest_configure()
ctest_build()
endfunction()
Usually, it should be enough to have your version control system tell
you if something has really changed. If so, you will want to do a
configure/build.
-Bill
--
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] Generator-independent incremental CMake run
Am 14.08.2014 16:31, schrieb David Cole: We have a fairly large project with about 400 targets. $ cmake %builddir% -> takes about 5 minutes for a No-op $ cmake --build %builddir% --target ZERO_CHECK -> takes 20 seconds for No-op This is the problem. "cmake %builddir%" should be as fast as possible for a no-op... If it's not, it would be good to solve the real underlying problem that causes it to take 5 minutes for "nothing" rather than write elaborate scripts to try to workaround it. I already had a look into our large generation time. They are multiple reasons, not one big issue which can be solved easily. But with all due respect, its not just a 'workaround'. I do not want to re-compile things that haven't changed, so i also do not want to re-generate if nothing has changed. A ZERO_CHECK (comparing timestamps of all used CMakeLists.txt) will always be faster than generating the project. Test with CMake 3.0.1 configuring CMake itself: $ git describe v3.0.1-1690-geb3b550 $ cmake --version cmake version 3.0.1 CMake suite maintained and supported by Kitware (kitware.com/cmake). $ time cmake build -- Configuring done -- Generating done -- Build files have been written to: D:/Playground/cmake/cmake/build real0m14.414s user0m0.000s sys 0m0.015s $ time cmake --build build --target ZERO_CHECK Microsoft (R) Build Engine version 4.0.30319.17929 [] real0m0.421s user0m0.000s sys 0m0.015s So ZERO_CHECK is 34 times faster. Why shouldn't I take advantage of that. Thank, Marc -- 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] Generator-independent incremental CMake run
We have a fairly large project with about 400 targets. $ cmake %builddir% -> takes about 5 minutes for a No-op $ cmake --build %builddir% --target ZERO_CHECK -> takes 20 seconds for No-op This is the problem. "cmake %builddir%" should be as fast as possible for a no-op... If it's not, it would be good to solve the real underlying problem that causes it to take 5 minutes for "nothing" rather than write elaborate scripts to try to workaround it. Is your project publicly available so CMake devs can try to figure out why it takes so long? Or... can you produce a generated repro case that demonstrates a long no-op time? There must be something in your project's CMake code that triggers the performance problem. Does it still happen with the latest release (CMake 3.0.1)? D -- 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] Generator-independent incremental CMake run
Am 14.08.2014 08:13, schrieb Hendrik Sattler: On 13. August 2014 21:40:34 MESZ, Nagger wrote: But what I really miss is an "--update" option for CMake which is doing all the work (updating if possible, configuring if necessary) internally. It would use the implementation of 'cmake --build' to trigger a re-configure and if that is not possible it would start a fresh configure&generate. Any thoughts about that? cmake $builddir does exactly that. This does not work here. "cmake $builddir" does a full configure&generate. (CMake version is 2.8.12) We have a fairly large project with about 400 targets. $ cmake %builddir% -> takes about 5 minutes for a No-op $ cmake --build %builddir% --target ZERO_CHECK -> takes 20 seconds for No-op The ZERO_CHECK visual studio target that is present in every cmake generated solution does this: it checks if cmake needs to be re-run. It is built before every other target. So your batch file does a lot of things that are already done by cmake. If the build is started from command line (cmake --build or msbuild directly) your wont get the "Project has changed! Abort and Reload?"-Dialog. The old solution will be build. You need to execute the build-process a seconds time. Or - as the script does - start a separate ZERO_CHECK before the actual build. Marc -- 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] ctest and tracks
OK, thanks for the informations. It's a lot more clear now. YC - Mail original - De: "David Cole" À: "ycollette nospam" , cmake@cmake.org Envoyé: Jeudi 14 Août 2014 13:33:01 Objet: Re: [CMake] ctest and tracks --track is the same as the TRACK argument to the ctest_start scripting command. http://www.cmake.org/cmake/help/v3.0/command/ctest_start.html It will send a dashboard to the named section of a CDash project page, but it will NOT create it. You have to create the track (called a "group" in the CDash admin pages) as the CDash project admin first before you can send to it. For example, on the VTK Wiki Examples dashboard, there is a "Wiki Examples" track/group/section, which was created by the project admin before dashboards were submitted to that track. http://open.cdash.org/index.php?project=VTKWikiExamples HTH, David C. -- 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] Regarding enviroment variables directly used in executables
A "SET(ENV{TARGET2_EXE_PATH} "C:/Test/Target2")" call in a CMakeLists
file only has an effect while CMake is running.
If you need the env var set for your batch file to run, you should pass
the value for it down in as an arg to the batch file, and then do:
set TARGET2_EXE_PATH=%~1
(no quotes in the batch file set, %~1 means arg 1 to the batch file,
but with any surrounding quotes stripped...)
HTH,
David
--
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
[CMake] Regarding enviroment variables directly used in executables
Hi David,
In our cmake project, we have the following scenario:
1. add_custom_command() call is as follows:
add_custom_command(TARGET ${TESTTARGETNAME}
POST_BUILD
COMMENT "Test
target 1..."
COMMAND
python ${CMAKE_SOURCE_DIR}/testthetargets.bat "TestTarget1" "${TESTBIN}"
)
2. The code in the batch file testthetargets.bat is as follows:
It invokes a project specific executable testtarget1.exe.
The source code of testtarget1.exe has calls to get few environment variables
using getenv() function call.
For example, a sample getenv() call is as follows:
target2_exe_path = getenv("TARGET2_EXE_PATH");
So, here the above getenv() call is supposed to get the value of environment
variable TARGET2_EXE_PATH.
Issue we are facing is as follows:
1. We set environment variable TARGET2_EXE_PATH using the following cmake
SET command before the add_custom_command() execution:
SET(ENV{TARGET2_EXE_PATH} "C:/Test/Target2")
2. But when the add_custom_command() gets executed, we observe that the
environment variable TARGET2_EXE_PATH is not getting reflected in the above
getenv() call in the source code of testtarget1.exe. The getenv() call returns
an empty string.
But this issue does not occur when TARGET2_EXE_PATH environment variable is set
from Windows directly (i.e. from System Properties -> Advanced -> Environment
Variables). In that case, TARGET2_EXE_PATH gets reflected in the above getenv()
call.
So, basically the call to SET(ENV{TARGET2_EXE_PATH} "C:/Test/Target2") has no
impact on the call to getenv() in the source code.
Kindly let us know if there is any other way in this case other than setting
the TARGET2_EXE_PATH environment variable from Windows directly ?
Thanks & Regards
Ravi Raman
Xoriant Solutions Pvt. Ltd
4th Floor, Winchester, Hiranandani Business Park, Powai, Mumbai 400076, INDIA.
Tel: +91 22 30511000,9930100026 Extn: 2144 Voip No. 4088344495/96/97/98 Voip
Extn:1178| Fax: +91 22 3051
ravi.ra...@xoriant.com|
http://www.xoriant.com
Re: [CMake] ctest and tracks
--track is the same as the TRACK argument to the ctest_start scripting command. http://www.cmake.org/cmake/help/v3.0/command/ctest_start.html It will send a dashboard to the named section of a CDash project page, but it will NOT create it. You have to create the track (called a "group" in the CDash admin pages) as the CDash project admin first before you can send to it. For example, on the VTK Wiki Examples dashboard, there is a "Wiki Examples" track/group/section, which was created by the project admin before dashboards were submitted to that track. http://open.cdash.org/index.php?project=VTKWikiExamples HTH, David C. -- 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
[CMake] ctest and tracks
Hello, I've have configured a project to use dash to save test results. On thing is not clear in the ctest documentation: what is the use of the --track option ? Does it allow to create a new category (like Weekly) and submit the test results to this new category ? Best regards, YC -- 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
