[CMake] TEST Property ENVIRONMENT combined with ctest --build-and-test

[Hugo Heden]

Good day all,

I am using ADD_TEST like this:

  ADD_TEST(
nameOfMyTest
${CMAKE_CTEST_COMMAND}
--build-and-test  ${CMAKE_SOURCE_DIR} ${CMAKE_BINARY_DIR}
--build-generator ${CMAKE_GENERATOR}
--build-makeprogram ${CMAKE_BUILD_TOOL}
--build-nocmake
--build-noclean
--build-project ${MY_PRODUCT_NAME}
--build-target someTestTarget
)

-- that is: *ctest --build-and-test* is invoked "from within" the 
test.*ctest --build-and-test* will in turn invoke the build tool:


*make someTestTarget*

(assuming Unix make is the build tool).

That's correct so far, isn't it?

Question:

I would now like to specify an environment variable in this 
CMakeLists.txt, namely "TJO=SAN", that affects the invocation of *make 
someTestTarget*. The result would be that ctest --build-and-test 
"creates" an invocation like:


*TJO=SAN make someTestTarget*

How can I do that? A naïve idea would be to write

SET_PROPERTY(TEST nameOfMyTest PROPERTY ENVIRONMENT "TJO=SAN" )

-- but that will not work (right?) Because it will only set the 
environment variable for the invocation of ctest:


*TJO=SAN ctest --build-and-test *

-- but /not/ the subsequent call to make.

Any ideas?

/Is there any way to tell *ctest --build-and-test* to set an environment 
variable for the invocation of the build tool?/


Best,

- Hugo Heden

FOI, Sweden
www.foi.se

___
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] How to make sure "make test" depends on "make all"

[Hugo Heden]

On Wed, Jun 24, 2009 at 2:08 PM, Shlomi Fish  wrote:

> On Tuesday 23 June 2009 11:57:16 Hugo Heden wrote:
> > On Tue, Jun 23, 2009 at 9:56 AM, Shlomi Fish 
> wrote:
> > > Hi all!
> > >
> > > I'm using cmake-2.6.4-3mdv2010.0 on Mandriva Linux Cooker, and ran into
> a
> > > problem. I want "make test" (which is a custom target) to depend on
> "make
> > > all", in this codebase:
> > >
> > >  <http://svn.berlios.de/svnroot/repos/fc-solve/trunk/fc-solve/source/>
> >
> > I can't say that I understand the error messages you're getting, but it
> is
> > unfortunately *not* possible to make built-in targets like "test", "all"
> > and "install" depend on each other. See for example this bug:
> >
> > http://public.kitware.com/Bug/view.php?id=8438
>
> Interesting. Is this a bug or a (mis-)feature? If I work on it and
> contribute
> a patch that will fix it, will it be accepted?
>
>
I think it is a "bug" (but I am just a user). See also one of the comments
in http://public.kitware.com/Bug/view.php?id=6348  -- I'll paste it here
(with some boldificiations that are purely mine -- I hope they don't screw
up the view too much for text-only viewers):

*Brad King:*

> What we really need is* a notion of a "local target"* that runs the same
> rule in every directory with that directory as the working directory. The
> rule would not be allowed to have any input or output files...just a command
> line to run unconditionally. On IDE generators the target would appear only
> once and always run in the top level. Currently the *"install", "test",
> and "clean" targets work like this*. It would have to *become a
> first-class feature*. I'd also want to convert the install, test, and
> clean targets to be defined this way in the first place. They could be
> created at the beginning of the configure step and *referencable by users*
> .
>
>
I am not sure whether this would mean that you can force "test" to depend on
"all" (which was your original concern), since "all" is not mentioned
above..? But forcing "test" to depend on "install" would work I guess.

/Hugo Heden
___
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] How to make sure "make test" depends on "make all"

[Hugo Heden]

On Tue, Jun 23, 2009 at 9:56 AM, Shlomi Fish  wrote:

> Hi all!
>
> I'm using cmake-2.6.4-3mdv2010.0 on Mandriva Linux Cooker, and ran into a
> problem. I want "make test" (which is a custom target) to depend on "make
> all", in this codebase:
>
>  


I can't say that I understand the error messages you're getting, but it is
unfortunately *not* possible to make built-in targets like "test", "all" and
"install" depend on each other. See for example this bug:

http://public.kitware.com/Bug/view.php?id=8438
___
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] Have "make clean" run a script?

[Hugo Heden]

I think that would be possible if
http://public.kitware.com/Bug/view.php?id=8438 was solved, so that you could
create a custom dependency on the clean-target.

On Thu, May 7, 2009 at 10:58 PM, Bill O'Hara  wrote:

> In addition to deleting files, is it possible to get the generated clean
> target to run a script?
>
> I want to do everything make clean does but also insert a call to a sanity
> script.
>
> thanks
> b.
>
> ___
> 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] A potential bug ?

[Hugo Heden]

On Sun, Apr 26, 2009 at 11:14 PM, Alexander Neundorf <
a.neundorf-w...@gmx.net> wrote:

> On Friday 24 April 2009, Theodore Papadopoulo wrote:
> > Alexander Neundorf wrote:
> > > On Friday 24 April 2009, Theodore Papadopoulo wrote:
> > > As an experience, I have tried to mimick the gnu make check as
> indicated
> > > in the web pages,
> > > Where ?
> >
> > http://www.cmake.org/Wiki/CMakeEmulateMakeCheck
> >
> > >> but decidedADD_DEPENDENCIES(test ${executable})
> > >> for some reason to keep the "test" target name. But when, I issuing a
> > >> ADD_DEPENDENCIES(test XXX)
> > >> cmake tells me that there is no dependency name "test", but when I'm
> > >> trying to add one, then it claims there
> > >
> > > CMake generates already a target named "test", but this is a "special
> > > target", you cannot use it with add_dependencies().
> > > Just use a different name for that.
> >
> > This I figured out. I find the behaviour puzzling. At the very least,
> > the command
> > ADD_DEPENDENCIES(test ${executable})
> > should issue a message such as "Test is a special target that cannot be
> > used with ADD_DEPENDENCIES",
> > instead of a "target test does not exists". Of course, making
> > ADD_DEPENDENCIES to work with target
> > test would be even better
>
> Please add that as a bug report in the bug tracker:
> http://public.kitware.com/Bug
>
>
Something very similar is reported here:
http://public.kitware.com/Bug/view.php?id=8438
___
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? A failure in add_custom_command/POST_BUILD does not propagate to target.

[Hugo Heden]

On Fri, Apr 17, 2009 at 10:19 PM, Alexander Neundorf <
a.neundorf-w...@gmx.net> wrote:

> On Friday 17 April 2009, Hugo Heden wrote:
> > The following example illustrates a possible bug.
> >
> > Consider the following CMakeLists.txt code. This little "project" should
> > fail when the target MyTarget is built (because one of the POST_BUILD
> > custom commands fails).
> >
> > ===
> > cmake_minimum_required(VERSION 2.6)
> >
> > PROJECT( test )
> >
> > ADD_CUSTOM_TARGET( MyTarget
> >   COMMENT "This is MyTarget"
> > )
> >
> > ADD_CUSTOM_COMMAND(
> > TARGET MyTarget
> > POST_BUILD
> > COMMAND cmake -E blablablahh # Error (intentional error, to
> illustrate
> > buggy behaviour.)
> > VERBATIM
> > )
> >
> > ADD_CUSTOM_COMMAND(
> >TARGET MyTarget
> >POST_BUILD
> >COMMAND cmake -E echo "hello there" # Success.
> >VERBATIM
> > )
> > =
> >
> > However, running
> >
> >   > cmake -G "Visual Studio 9 2008" ..\source
> >   > devenv test.sln /Build Debug /Project MyTarget.vcproj
> >
> > succeeds, which is not expected. (Right?).
> >
> > The problem seems to be that a succeeding custom command comes after the
> > failing one, and this sort of *hides* the failure somehow.. The fact that
> > failures are hidden like this is of course dangerous. (We have tests that
> > have been failing like this for a while that have not shown up as error
> in
> > our nightly builds.) When using other Generators and build tools (I have
> > tested with "NMake Makefiles" -- nmake on Windows and "Unix Makefiles" --
> > Gnu-make on Linux) the build phase fails as expected.
> >
> >   > cmake --version
> >
> >   cmake version 2.6-patch 2
> >
> > Any comments?
>
> Please report this as a bug in the bug tracker.
>

Done, see http://public.kitware.com/Bug/view.php?id=8906

/Hugo Heden
___
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

[CMake] Bug? A failure in add_custom_command/POST_BUILD does not propagate to target.

[Hugo Heden]

The following example illustrates a possible bug.

Consider the following CMakeLists.txt code. This little "project" should
fail when the target MyTarget is built (because one of the POST_BUILD custom
commands fails).

===
cmake_minimum_required(VERSION 2.6)

PROJECT( test )

ADD_CUSTOM_TARGET( MyTarget
  COMMENT "This is MyTarget"
)

ADD_CUSTOM_COMMAND(
TARGET MyTarget
POST_BUILD
COMMAND cmake -E blablablahh # Error (intentional error, to illustrate
buggy behaviour.)
VERBATIM
)

ADD_CUSTOM_COMMAND(
   TARGET MyTarget
   POST_BUILD
   COMMAND cmake -E echo "hello there" # Success.
   VERBATIM
)
=

However, running

  > cmake -G "Visual Studio 9 2008" ..\source
  > devenv test.sln /Build Debug /Project MyTarget.vcproj

succeeds, which is not expected. (Right?).

The problem seems to be that a succeeding custom command comes after the
failing one, and this sort of *hides* the failure somehow.. The fact that
failures are hidden like this is of course dangerous. (We have tests that
have been failing like this for a while that have not shown up as error in
our nightly builds.) When using other Generators and build tools (I have
tested with "NMake Makefiles" -- nmake on Windows and "Unix Makefiles" --
Gnu-make on Linux) the build phase fails as expected.

  > cmake --version
  cmake version 2.6-patch 2

Any comments?

Thanks

Hugo Heden
Swedish Defence Research Agency
Stockholm, Sweden
___
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

[CMake] ctest --build-and-test merges all output to stdout?

[Hugo Heden]

Good day all,

I am running

   $ ctest --build-and-test ... [etc]

and it seems that ctest *merges* all output from subprocess on to
*stdout* and writes nothing on *stderr*. Is this expected behaviour?
Can I change it? What I would prefer would be for ctest to just "pass
along" whatever the subprocesses print on those streams to *the same
output stream*. (I am trying to write nightly build scripts that relay
information as relevant as possible to various sinks.) Any hints
appreciated!

Just as an example, if I specify a --build-target with incorrect
spelling, the underlying /usr/bin/make will emit an output to
*stderr*, like this:

   $ make spelcheck
   make: *** No rule to make target `spelcheck'.  Stop.

But if I do the same via ctest, that output ends up on  *stdout*:

   $ ctest -VV --debug --build-and-test ../SourceWC/foo .
--build-generator "Unix Makefiles" --build-makeprogram "/usr/bin/make"
--build-project merlin --build-config Debug --build-nocmake
--build-noclean --build-target spelcheck
   /home/kitware/CMakeReleaseDirectory/CMake-2-6-2/Source/ctest.cxx:275
Internal cmake changing into directory: /tmp/build   Change Dir:
/tmp/build
   Run Build Command:/usr/bin/make "spelcheck"
   make: *** No rule to make target `spelcheck'.  Stop.

Best regards

Hugo Heden
___
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] "unit" testing your CMakeLists.txt

[Hugo Heden]

2009/2/11 Tyler Roscoe :
> Bumping this one time. Any thoughts? Is there a better place to ask this
> sort of question?
>

Just wanted to say that I'm interested too, so I'd follow any
discussion with interest.

Best regards

Hugo Heden

> Thanks,
> tyler
>
> On Mon, Feb 09, 2009 at 12:15:33PM -0800, Tyler Roscoe wrote:
>> My company is adopting Test-Driven Development. I am wondering if any of
>> you build engineers in a similar position have given any thought to how
>> one might use this approach when developing your build systems.
>>
>> In one sense, you can say, "Well, the build is the test. If I say 'go'
>> and I end up with SuperProduct.exe (and maybe a bunch of unit test
>> successes) then everything works and I don't need any tests."
>>
>> OTOH, it would be nice to gain some of the benefits of TDD (e.g.,
>> fearless refactoring) in the build system. Sometimes there are build
>> artifacts that should be generated which are not code and therefore
>> won't generate "build errors" (documentation perhaps).
>>
>> One approach I've thought of is a simple script that simply makes
>> sure that each CMake project deposits an expected list of files in a
>> certain place. I have a hierarchy of "buildables" so it might be nice to
>> know that the header at the bottom of the dependency tree is built
>> correctly, and that the libraries that use it find that header and build
>> correctly, and that the executable that use those libraries find
>> everything and build correctly.
>>
>> Does anyone do anything like this? Are there tools around to help? Is
>> this a worthwhile thing to think about?
> ___
> 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] Adding install dependency to test-target?

[Hugo Heden]

>
> If I do this:
>
>LIST(APPEND extra_libopts_clean_files
>./libopts/.libs/libopts.o
>./libopts/.libs/libopts.la
>./libopts/.libs
>./libopts/_libs
>./libopts/libopts.la
>./libopts/so_locations
>./libopts/*.o
>./libopts/*.lo
>)
>
>SET_DIRECTORY_PROPERTIES(PROPERTIES
>ADDITIONAL_MAKE_CLEAN_FILES ${extra_libopts_clean_files})
>
> I get an error about too many args to SET_DIRECTORY_PROPERTIES.

Try using quotes:

SET_DIRECTORY_PROPERTIES(PROPERTIES
   ADDITIONAL_MAKE_CLEAN_FILES "${extra_libopts_clean_files}" )

> And
> If I specify each file individually, it appears that only the last
> takes effect (basically subsequent calls overwrite the previous
> value).  Surely there is a way to specify multiple files right?
>

In such a case, you could use the APPEND functionality in set_property:
http://www.cmake.org/cmake/help/ctest2.6docs.html#command:set_property

SET_PROPERTY(
  DIRECTORY "${CMAKE_CURRENT_SOURCE_DIRECTORY}"
  APPEND
  ADDITIONAL_MAKE_CLEAN_FILES "./libopts/.libs/libopts.la"
)

But beware of this issue when using ADDITIONAL_MAKE_CLEAN_FILES

http://public.kitware.com/Bug/view.php?id=8164

-- if there is no *target* present in the CMakeLists.txt, then the
directory does not count as a "directory" in the cmake sense, so the
directory property will be ignored.


> Honestly, both of these solutions are just hacks it seems like
> cmake really should have a way to add to the 'clean' and 'install'
> pseudo-targets.
>

I agree. This issue is apparently known though, so be patient, see
Brad Kings comment: http://public.kitware.com/Bug/view.php?id=8438 --
thanks Brad!

Best regards
Hugo Heden
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Adding install dependency to test-target?

[Hugo Heden]

2008/11/20 Eric Noulard :
> 2008/11/20 Hugo Heden :
>> Good day all,
>>
>>
>> Is there any way that I can add 'install' dependency to the 'test'-target?
>>
>> Doing
>>
>>  add_dependencies( test install )
>>
>> does not seem to work:
>>  CMake Error at ... (ADD_DEPENDENCIES):
>> add_dependencies Adding dependency to non-existent target: test
>
> I don't think it's possible to add dependencies to "built-in" CMake target
> (which deserve a feature request :-)
>
>> Apparently neither 'test' nor 'install' counts as "top-level-targets"?
>
> Precisely :=)
>

Feature request added: http://public.kitware.com/Bug/view.php?id=8438

Best regards
Hugo Heden
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

[CMake] Visual Studio reports errors based on output of custom commands

[Hugo Heden]

Good day all,

(Not sure if most people already know this, but I thought it might be
useful to record this "somewhere on the Internet" for future
reference)

Visual Studio sometimes reports errors from custom commands (or custom
targets) even though they exit with zero, if they output certain
strings. An example output string that would trigger an error is
"hejsan: error : ".

The string at least contains a colon, after that the string "error"
(without the quotes) and after that another colon. This effect can be
recreated by creating a custom command (within a Visual Studio
project) that just prints that string. Also, the following little
cmake-project can be used to illustrate this effect. Notice the
difference between target1 and target2 below.

This is not ideal for us. Sometimes our code prints stuff like that,
even though there is no real error. Example: Test code that *checks*
that a certain asserts *fires* at some condition (a *negative* test).
The assert may very well print a string that Visual Studio triggers
on.

I am not sure whether this is to be considered a cmake issue at all?

Best regards
Hugo Heden




CMAKE_MINIMUM_REQUIRED( VERSION 2.6 )

PROJECT( small_cmake_proj )

ADD_CUSTOM_TARGET(
  target1
  ALL
  COMMAND echo "hoppsan: error: tjosan"
  VERBATIM
  )

ADD_CUSTOM_TARGET(
  target2
  ALL
  COMMAND echo "hoppsan: horror: tjosan"
  VERBATIM
  )



Build this, for example using a "Visual Studio 2008 Command Prompt":



> cmake ..\src -G "Visual Studio 9 2008"


> devenv small_cmake_proj.sln /Build Debug /project ALL_BUILD.vcproj

 Microsoft (R) Visual Studio Version 9.0.21022.8.
 Copyright (C) Microsoft Corp. All rights reserved.
 -- Build started: Project: target1, Configuration: Debug Win32 --
 "hoppsan: error: tjosan"
 Build log was saved at
"file://c:\devel\test\small_cmake_proj\build\target1.dir\Debug\BuildLog.htm"
 target1 - 1 error(s), 0 warning(s)
 -- Build started: Project: target2, Configuration: Debug Win32 --
 "hoppsan: horror: tjosan"
 Build log was saved at
"file://c:\devel\test\small_cmake_proj\build\target2.dir\Debug\BuildLog.htm"
 target2 - 0 error(s), 0 warning(s)
 == Build: 1 succeeded, 1 failed, 2 up-to-date, 0 skipped ==
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] add_custom_target always runs?

[Hugo Heden]

2008/12/16 Tyler Roscoe :
> I am using what I think is a common pattern to create some headers.
> Following the example at
> http://www.cmake.org/Wiki/CMake_FAQ#How_do_I_generate_an_executable.2C_then_use_the_executable_to_generate_a_file.3F,
> I have an add_custom_command which calls a script (generateheader.py):
>
> add_custom_command (
>DEPENDS generateheader.py
>OUTPUT  results/header.h
>COMMAND ${PYTHON_EXECUTABLE}
>ARGS generateheader.py --infile=src/header.in.h --outfile=results/header.h
> )
>
> And then I have an add_custom_target to wrap the command in a target:
>
> add_custom_target (
>generateheader ALL
>DEPENDS results/header.h
> )
>
> This seems to mostly do what it's supposed to do. When I run "make all",
> the generateheader target runs and results/header.h is created. When I
> run "make generateheader", same thing.
>
> So now the problem.
>
> When I do "make all", the generateheader target *always* runs, even if
> results/header.h and generateheader.py are up-to-date.
>
> This is a problem because other targets depend on generateheader, so
> when generateheader runs, all the dependent targets also run. This makes
> it impossible for me to do a delta build.
>
> Some closer reading of the manual suggests that this is by design. From
> http://www.cmake.org/cmake/help/cmake2.6docs.html#command:add_custom_target:
>
> "Adds a target with the given name that executes the given commands. The
> target has no output file and is ALWAYS CONSIDERED OUT OF DATE even if
> the commands try to create a file with the name of the target."
>

I just want to clarify that what you have been doing looks correct,
and it should do exactly what you want.

Yes, the target from ADD_CUSTOM_TARGET is always out-of-date so it
will be invoked every time. That means that if you would have a
COMMAND in the target (which you don't), that command would be run
every time, like the command "blablabla" below:

 add_custom_target (
generateheader ALL
DEPENDS results/header.h
COMMAND blablabla
 )


*And* this implies that all dependencies are *checked* as well, like
for example "results/header.h" above, which "connects" to the OUTPUT
of the ADD_CUSTOM_COMMAND:

add_custom_command (
   DEPENDS generateheader.py
   OUTPUT  results/header.h
   COMMAND ${PYTHON_EXECUTABLE}
   ARGS generateheader.py --infile=src/header.in.h --outfile=results/header.h
)


*But* that does not mean that the dependencies needs to be actually
*rebuilt* every time. They shouldn't. So there should be no problem
marking the target with "ALL".

Now, the reason that the dependency in your case is rebuilt every time
is not clear from your post; but do double-check that the DEPENDS of
the target is actually satisfied the second target is invoked -- are
you absolutely sure that "results/header.h" exists (the second time
the target is invoked)? As someone suggested, do try using an absolute
path instead of a relative one, to make any errors easier to spot.

Best regards

Hugo Heden

> Ok, so is it simply impossible to do delta builds if my build process
> needs add_custom_command/add_custom_target invocations? Is there some
> better way to have CMake create the headers for me? Does this behavior
> of add_custom_target only occur when I add a new target dependent on
> ALL?
>
>
> Thanks,
> tyler
> ___
> CMake mailing list
> CMake@cmake.org
> http://www.cmake.org/mailman/listinfo/cmake
>
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Should changing, adding or removing add_definitions call trigger a recompile of affected files

[Hugo Heden]

2008/12/10 Philip Lowman <[EMAIL PROTECTED]>:
> On Tue, Dec 9, 2008 at 1:08 PM, Philip Lowman <[EMAIL PROTECTED]> wrote:
>>
>> This is a known problem.  Visual Studio has no way of knowing that the
>> compiler flags changed in a project file CMake is writing to.
>>
>> I would love to see a patch for this for CMake 2.8.
>
> One thought I had here was to have the "vcbuild" command clean any affected
> projects.  This would have the advantage of isolating CMake from
> implementing any Visual Studio specific mods (i.e. delete these object files
> to force a recompilation, etc.).  This would have some downsides though.
>
> 1. The easiest implementation would just be to perform the clean if a
> project file changes.  This would result in more cleaning then necessary as
> changing source files (for example) shouldn't cause a rebuild.  Certain
> project modifications like adding a source file to a target shouldn't cause
> a clean of that target.
>
> 2. Perhaps the biggest gotcha of all, "cleaning" a target would wipe out any
> binaries/libraries already generated.  This is far different from the
> behavior of CMake's Makefile generator which simply causes targets to be
> rebuilt on the next "make".
>
> Anyone have any ideas for fixing this?  I've been bit by this one before
> (forgetting to rebuild everything when I change a preprocessor definition at
> the global scope).
>

By dropping support for Visual Studio-style generators? Come on, admit
it, wouldn't that be so relieving? :-)
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Question about install()

[Hugo Heden]

2008/12/9 Robert Dailey <[EMAIL PROTECTED]>:
> On Tue, Dec 9, 2008 at 11:05 AM, Robert Dailey <[EMAIL PROTECTED]> wrote:
>>
>> Michael,
>>
>> Is there a way to call add_custom_command() on a specific configuration
>> for a specific target? If I can do this then I can use CMAKE to copy the
>> files  appropriately and your method would work perfectly.
>>
>> Thanks for your tme.
>
> After much research, I've found out that CMake cannot provide a custom
> command (Post build event) to a specific configuration in the case where
> CMake is used to generate a multi-configuration target, such as a visual
> studio project. This is a HUGE problem for me. Are there any work-arounds
> for this issue? Does this issue plan to be addressed in a future release
> (Hopefully soon)?
>

I wonder if you could use the "ctest --build-and-test" tool, telling
it to configure (run cmake on) some custom little CMakeLists.txt-file
that could perform the copying. The "ctest --build-and-test" tool can
be given the "--build-config-sample" flag, that helps figuring out
whether it is a Debug or Release build currently going on. ctest can
thusly set  the CMAKE_BUILD_TYPE variable when invoking cmake on that
custom CMakeLists.txt-file, so that the latter could perform the
copying based on that variable.

I'm not sure that I understand your problem correctly (and it's in the
middle of the night here) so I will not explain more now ... but take
a look at the following example and see if it is possible to
understand what it does .. (Note that it needs to be adapted for the
case where CMAKE_BUILD_TYPE is set as well in order to be generic, but
that is easy)

Best regards

Hugo Heden
Stockholm, Sweden


CMAKE_MINIMUM_REQUIRED(VERSION 2.6)

PROJECT(test)

# Create some dummy source (on the fly, but that is not necessary) and
#make sure it is compiled using a subdirectory with a CMakeLists.txt.
#The "ctest --build-and-test" (below) will later use the directory in which
#the executable ends up to figure out what build type this is. This is what
#the --build-config-sample flag is for.

FILE( WRITE
  ${CMAKE_CURRENT_BINARY_DIR}/dummy_src/CMakeLists.txt
  "ADD_EXECUTABLE( dummy dummy.cpp )"
  )

FILE( WRITE
  ${CMAKE_CURRENT_BINARY_DIR}/dummy_src/dummy.cpp
  "int main(){}"
  )

ADD_SUBDIRECTORY(
  ${CMAKE_CURRENT_BINARY_DIR}/dummy_src/
  ${CMAKE_CURRENT_BINARY_DIR}/dummy_build/
  )

ADD_CUSTOM_TARGET( some_target
  ALL
  DEPENDS dummy
  COMMAND
${CMAKE_CTEST_COMMAND}
--build-and-test ${CMAKE_CURRENT_BINARY_DIR}/tmp_custom_command
${CMAKE_CURRENT_BINARY_DIR}/tmp_custom_command
--build-generator ${CMAKE_GENERATOR}
--build-makeprogram ${CMAKE_BUILD_TOOL}
--build-noclean
--build-config-sample ${CMAKE_CURRENT_BINARY_DIR}/dummy_build/dummy
#--build-config ${CMAKE_BUILD_TYPE}
)

# Ok, finally, this is the CMakeLists.txt that will be "invoked" by the
#ctest-command above.. (here we create it on the fly, but that is
# not necessary)

FILE( WRITE
  ${CMAKE_CURRENT_BINARY_DIR}/tmp_custom_command/CMakeLists.txt
  "
  MESSAGE( STATUS \"Woh - There is a build going on with
build type: \${CMAKE_BUILD_TYPE}\")
  IF( \${CMAKE_BUILD_TYPE} STREQUAL \"Debug\" )
MESSAGE( STATUS \"Woh - here we could copy Debug-dll:s
to some Debug destination directory.\")
  ELSEIF( \${CMAKE_BUILD_TYPE} STREQUAL \"Release\" )
MESSAGE( STATUS \"Woh - here we could copy
Release-dll:s to some Release destination directory.\")
  ENDIF( \${CMAKE_BUILD_TYPE} STREQUAL \"Debug\" )
 "
)
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] How to make ctest not buffer its output?

[Hugo Heden]

2008/12/5 Hugo Heden <[EMAIL PROTECTED]>:
> 2008/12/5 Daniel Nelson <[EMAIL PROTECTED]>:
>> Alexander Neundorf wrote:
>>>
>>> On Thursday 04 December 2008, Hugo Heden wrote:
>>>>
>>>> Good day all,
>>>>
>>>> I use ctest --build-and-test to do some stuff that takes a long time.
>>>> It seems that ctest buffers the output of its subcommands so that
>>>> nothing is written (to the "terminal") until at the end. This is a
>>>> little unconvenient -- as a human I feel more comfortable actually
>>>> seeing that "something is happening".
>>>>
>>>> Is there a way I can force ctest to not buffer the output of
>>>> subcommands, but rather just flush it?
>>>
>>> Does ctest -VV do what you want ?
>>> It switches to "extra verbose" mode.
>>>
>
> No, ctest still buffers the output until the whole build-and-test
> process finishes.
>
>>
>> I submitted this some time ago as bug 0005814.  I don't believe there is a
>> way to view the output until the test finishes.
>
> Ah, thank you. The bug is here: http://public.kitware.com/Bug/view.php?id=5814
>
> Yes, that reflects my issue exactly.
>

I added a little comment to support that bug report. Thanks Daniel.

Hugo Heden
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] How to make ctest not buffer its output?

[Hugo Heden]

2008/12/5 Daniel Nelson <[EMAIL PROTECTED]>:
> Alexander Neundorf wrote:
>>
>> On Thursday 04 December 2008, Hugo Heden wrote:
>>>
>>> Good day all,
>>>
>>> I use ctest --build-and-test to do some stuff that takes a long time.
>>> It seems that ctest buffers the output of its subcommands so that
>>> nothing is written (to the "terminal") until at the end. This is a
>>> little unconvenient -- as a human I feel more comfortable actually
>>> seeing that "something is happening".
>>>
>>> Is there a way I can force ctest to not buffer the output of
>>> subcommands, but rather just flush it?
>>
>> Does ctest -VV do what you want ?
>> It switches to "extra verbose" mode.
>>

No, ctest still buffers the output until the whole build-and-test
process finishes.

>
> I submitted this some time ago as bug 0005814.  I don't believe there is a
> way to view the output until the test finishes.

Ah, thank you. The bug is here: http://public.kitware.com/Bug/view.php?id=5814

Yes, that reflects my issue exactly.

Hugo Heden
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

[CMake] How to make ctest not buffer its output?

[Hugo Heden]

Good day all,

I use ctest --build-and-test to do some stuff that takes a long time.
It seems that ctest buffers the output of its subcommands so that
nothing is written (to the "terminal") until at the end. This is a
little unconvenient -- as a human I feel more comfortable actually
seeing that "something is happening".

Is there a way I can force ctest to not buffer the output of
subcommands, but rather just flush it?

Best regards

Hugo Heden
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Invoke a target on a separate project in a generic way?

[Hugo Heden]

2008/12/4 Bill Hoffman <[EMAIL PROTECTED]>:
> Hugo Heden wrote:
>>
>> Good day all,
>>
>> I am looking for a way within a CMakeLists.txt make sure that:
>>
>> -- at *build* time
>>
>> -- cmake is invoked on a *separate* project, and then also the
>> "all"-target is invoked
>>
>> How do I do that?
>>
>> The following is a first rough sketch (that is not good enough, I
>> believe):
>>
>> ADD_CUSTOM_TARGET(
>>  build_separate_project
>>  WORKING_DIRECTORY separate_project/build
>>  COMMAND ${CMAKE_COMMAND} ../src
>>  COMMAND ${CMAKE_BUILD_TOOL} all
>> )
>>
>> -- The above only works for a ${CMAKE_BUILD_TOOL} that happens to
>> accept a commandline that contains a target and nothing else (like
>> GNU-make does).
>>
>> So is there a more *generic* way to, at build time, invoke cmake and
>> then the "all"-target on a separate project?
>>
>> (The following is a bit of background: We have a project called "FOO"
>> that generates source code that eventually also needs to be compiled.
>> The generated source files end up in a *directory* that is known
>> CMake-time, but the *filenames* are not known until *build*-time. Thus
>> there is no way with in project "FOO" to create a target to compile
>> the generated source-code. (Doing FILE(GLOB...) within project FOO
>> will not work, because the globbing will take place at cmake-time, at
>> which time there are no files there). Therefore, together with the
>> generated source files we generate a CMakeLists.txt that defines a
>> *separate* project called "BAR" that contains a target to compile the
>> generated source code. Hence the question above -- how do I invoke the
>> all target in the BAR project in a way that works for all build-tools,
>> not only GNU-make?)
>>
>
> You should look at ctest --build-and-test.  It can do what you want, and
> invoke all build systems supported by CMake.  It is used in the testing of
> CMake.  See CMake/Tests/CMakeLists.txt, and ctest --help for information.
>

Aha, yes, that's it! Thank you!

/Hugo Heden
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Invoke a target on a separate project in a generic way?

[Hugo Heden]

2008/12/4 Hugo Heden <[EMAIL PROTECTED]>:
> Good day all,
>
> I am looking for a way within a CMakeLists.txt make sure that:
>
> -- at *build* time
>
> -- cmake is invoked on a *separate* project, and then also the
> "all"-target is invoked
>
> How do I do that?
>

Before anyone else answers this: I think I should be looking at
try_compile, it seems to do what I am looking for. (I will get back
here and report, for future reference if nothing else.)

http://cmake.org/cmake/help/cmake2.6docs.html#command:try_compile


try_compile: Try compiling some code.

  try_compile(RESULT_VAR bindir srcdir
  projectName  [CMAKE_FLAGS ]
  [OUTPUT_VARIABLE var])

Try compiling a program. In this form, srcdir should contain a
complete CMake project with a CMakeLists.txt file and all sources. The
bindir and srcdir will not be deleted after this command is run. If
 is specified then build just that target otherwise the
all or ALL_BUILD target is built.
...
...






> The following is a first rough sketch (that is not good enough, I believe):
>
> ADD_CUSTOM_TARGET(
>  build_separate_project
>  WORKING_DIRECTORY separate_project/build
>  COMMAND ${CMAKE_COMMAND} ../src
>  COMMAND ${CMAKE_BUILD_TOOL} all
> )
>
> -- The above only works for a ${CMAKE_BUILD_TOOL} that happens to
> accept a commandline that contains a target and nothing else (like
> GNU-make does).
>
> So is there a more *generic* way to, at build time, invoke cmake and
> then the "all"-target on a separate project?
>
> (The following is a bit of background: We have a project called "FOO"
> that generates source code that eventually also needs to be compiled.
> The generated source files end up in a *directory* that is known
> CMake-time, but the *filenames* are not known until *build*-time. Thus
> there is no way with in project "FOO" to create a target to compile
> the generated source-code. (Doing FILE(GLOB...) within project FOO
> will not work, because the globbing will take place at cmake-time, at
> which time there are no files there). Therefore, together with the
> generated source files we generate a CMakeLists.txt that defines a
> *separate* project called "BAR" that contains a target to compile the
> generated source code. Hence the question above -- how do I invoke the
> all target in the BAR project in a way that works for all build-tools,
> not only GNU-make?)
>
> Best Regards
>
> Hugo Heden
>
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

[CMake] Invoke a target on a separate project in a generic way?

[Hugo Heden]

Good day all,

I am looking for a way within a CMakeLists.txt make sure that:

-- at *build* time

-- cmake is invoked on a *separate* project, and then also the
"all"-target is invoked

How do I do that?

The following is a first rough sketch (that is not good enough, I believe):

ADD_CUSTOM_TARGET(
  build_separate_project
  WORKING_DIRECTORY separate_project/build
  COMMAND ${CMAKE_COMMAND} ../src
  COMMAND ${CMAKE_BUILD_TOOL} all
)

-- The above only works for a ${CMAKE_BUILD_TOOL} that happens to
accept a commandline that contains a target and nothing else (like
GNU-make does).

So is there a more *generic* way to, at build time, invoke cmake and
then the "all"-target on a separate project?

(The following is a bit of background: We have a project called "FOO"
that generates source code that eventually also needs to be compiled.
The generated source files end up in a *directory* that is known
CMake-time, but the *filenames* are not known until *build*-time. Thus
there is no way with in project "FOO" to create a target to compile
the generated source-code. (Doing FILE(GLOB...) within project FOO
will not work, because the globbing will take place at cmake-time, at
which time there are no files there). Therefore, together with the
generated source files we generate a CMakeLists.txt that defines a
*separate* project called "BAR" that contains a target to compile the
generated source code. Hence the question above -- how do I invoke the
all target in the BAR project in a way that works for all build-tools,
not only GNU-make?)

Best Regards

Hugo Heden
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Rebuild target when external library changes?

[Hugo Heden]

2008/12/3 Bill Hoffman <[EMAIL PROTECTED]>:
> Lezz Giles wrote:
>>
>>
>> I have a project set up that imports libraries, and I want to relink if
>> those imported libraries change;
>>
>>
>> For example, in a directory I have
>>
>> hellow.c
>>
>> libfred.a
>>
>> CMakeLists.txt
>>
>>
>> where CMakeLists.txt contains:
>>
>> -
>>
>> LINK_DIRECTORIES(.)
>>
>> ADD_EXECUTABLE(hellow hellow.c)
>>
>> TARGET_LINK_LIBRARIES(hellow fred)
>>
> This should work:
>
> target_link_libraries(hellow ${CMAKE_CURRENT_SOURCE_DIR}/libfred.a)
>
> CMake has to know the full path to the library in order to create a
> dependency.   You could also use find_library to find libfred.
>

Hi,

Is there a reason for why CMake does not complain about the OP:s
suggestion, "TARGET_LINK_LIBRARIES(hellow fred)"?

In general, I would want CMake to be stricter and complain more, to
make it faster catching bugs like this . Is there a way (a command
line flag, a variable or something) to make CMake stricter?

Best regards
Hugo Heden
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] INCLUDE_DIRECTORIES in sub-directories doesn't work?

[Hugo Heden]

2008/11/26 Bill Hoffman <[EMAIL PROTECTED]>:
> The concept of a directory property in CMake is not one to one with the disk
> directories.   A directory in CMake is a directory that has a list of
> targets in it.  You can have a target that uses files from all sorts of
> different directories.   So, a directory property is not what you want.

( Off-topic;

Ahaaa, that must be the reason for why

set_directory_properties( properties additional_clean_files ... )

is not respected if no *target* present in the "directory"

I've added a note to http://public.kitware.com/Bug/view.php?id=8164

Best Regards
Hugo Heden
)
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] dependency of dependency

[Hugo Heden]

2008/11/26 Mathieu Malaterre <[EMAIL PROTECTED]>:
> Hi there,

Hi there!

>
>  I remember there is now a new behavior in cmake where you can
> specify not to pull a dependency of dependency. For instance my
> project is linking to vtk which itself is linking to libtiff. If I do
> not have libtiff.so (the symlink), I get error.
>
>
> make[3]: *** No rule to make target `/usr/lib/libtiff.so', needed by
> `bin/libvtkgdcm.so.2.0.9'.  Stop.
> make[3]: Leaving directory `/tmp/buildd/gdcm-2.0.9/debian/build-python2.4'
>
>
>  From gdcm I am not explicitely linking to libtiff, simlpy to
> libvtkIO. How can I avoid this behavior (all my libs are shared libs)
> ?

Perhaps by setting property LINK_INTERFACE_LIBRARIES to ""? Example follows.

/Hugo Heden


TARGET_LINK_LIBRARIES( mylib otherlib )

# http://www.vtk.org/Bug/view.php?id=3490 ..When other executables and
# shared libraries link to libmylib.so, they should not necessarily
# link to the stuff that libmylib.so linked to, just because
# libmylib.so linked to them. (That is otherwise the default in
# CMake). So we have to do this:
SET_PROPERTY( TARGET mylib PROPERTY LINK_INTERFACE_LIBRARIES "" )



>
> Thank you
> --
> Mathieu
> ___
> CMake mailing list
> CMake@cmake.org
> http://www.cmake.org/mailman/listinfo/cmake
>
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Default parameters in macros

[Hugo Heden]

>>> Are all macro parameters optional by default? If not, how can I make them
>>> optional? I have a couple of required parameters and a few optional ones.
>>> Thanks.
>>
>> You can use the ${ARGV} special variable in macros to iterate over all
>> provided arguments.

> Would that be all arguments or only unnamed ones?

${ARGV} get you all args, ${ARGN} gives you the unnamed ones only. I
think. Better double check:

http://cmake.org/cmake/help/cmake2.6docs.html#command:macro

Hugo Heden



2008/11/25 Sean Soria <[EMAIL PROTECTED]>:
> Would that be all arguments or only unnamed ones?
>
> On Tue, Nov 25, 2008 at 12:46 PM, Alexander Neundorf
> <[EMAIL PROTECTED]> wrote:
>> On Tuesday 25 November 2008, Robert Dailey wrote:
>>> Hi,
>>>
>>> Are all macro parameters optional by default? If not, how can I make them
>>> optional? I have a couple of required parameters and a few optional ones.
>>> Thanks.
>>
>> You can use the ${ARGV} special variable in macros to iterate over all
>> provided arguments.
>>
>> Alex
>> ___
>> CMake mailing list
>> CMake@cmake.org
>> http://www.cmake.org/mailman/listinfo/cmake
>>
> ___
> CMake mailing list
> CMake@cmake.org
> http://www.cmake.org/mailman/listinfo/cmake
>
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Bug? additional_clean_files not respected if no target present in directory

[Hugo Heden]

2008/11/18 Hugo Heden <[EMAIL PROTECTED]>:
> Good day all,
>
> It seems that
>
>   set_directory_propersties( properties additional_clean_files ... )
>
> is not respected if no target present in the directory -- that is
> 'make clean' will not remove the specified "additional clean file".

Reported bug:
http://public.kitware.com/Bug/view.php?id=8164

Best Regards
Hugo Heden

>
> Is this possibly a CMake bug, or is it rather a misunderstanding on my part?
>
> $ cmake --version
> cmake version 2.6-patch 2
>
> A little test case to illustrate this follows. We have two
> CMakeLists.txt-files, one in the root directory and one in a sub
> directory.  The former (src/CMakeLists.txt) is not really important,
> but included here for completeness. The latter,
> src/subdir/CMakeLists.txt, is where the bug appears. There is also a
> file that is being installed, src/subdir/hello.txt. Invoking 'make
> clean' will not clean that file unless there is an actual target
> specified in src/subdir/CMakeLists.txt.
>
> File tree:.
>
> |-- build
> |-- install
> `-- src
>|-- CMakeLists.txt
>`-- subdir
>|-- CMakeLists.txt
>`-- hello.txt
>
> 
> --- src/CMakeLists.txt:
>
> CMAKE_MINIMUM_REQUIRED(VERSION 2.6)
> SET( CMAKE_INSTALL_PREFIX ${CMAKE_SOURCE_DIR}/../install )
>
> ADD_SUBDIRECTORY( subdir )
>
> ADD_CUSTOM_TARGET(
>  some_target
>  COMMAND ${CMAKE_COMMAND} -E echo HELLO
> )
>
>
> 
> --- src/subdir/CMakeLists.txt:
>
> #ADD_CUSTOM_TARGET(
> #  some_subdir_target
> #  COMMAND ${CMAKE_COMMAND} -E echo WHOHOO
> #)
>
> INSTALL(
>  FILES hello.txt
>  DESTINATION ./
>  )
>
> SET_DIRECTORY_PROPERTIES(
>  PROPERTIES
>  ADDITIONAL_MAKE_CLEAN_FILES
>  ${CMAKE_INSTALL_PREFIX}/hello.txt
>  )
>
> ---
> ---
>
> As written above, with the target "some_subdir_target" commented out,
> the ADDITIONAL_MAKE_CLEAN_FILES will not be respected - - it seems to
> be sort of optimized away:
>
> $ cd build/
> $ cmake ../src
> ...
> ...
> $ make install
> ...
> $ ls ../install
> hello.txt
> $ make clean
> $ ls ../install/
> hello.txt   # <--- OUCH
>
>
> 
> 
>
> However, if the target is not commented out it will all work nicely:
>
> 
> --- src/subdir/CMakeLists.txt:
>
> ADD_CUSTOM_TARGET(
>  some_subdir_target
>  COMMAND ${CMAKE_COMMAND} -E echo WHOHOO
> )
>
> INSTALL(
>  FILES hello.txt
>  DESTINATION ./
>  )
>
> SET_DIRECTORY_PROPERTIES(
>  PROPERTIES
>  ADDITIONAL_MAKE_CLEAN_FILES
>  ${CMAKE_INSTALL_PREFIX}/hello.txt
>  )
>
> ----
> 
>
>
> $ cd build/
> $ cmake ../src
> ...
> ...
> $ make install
> ...
> $ ls ../install
> hello.txt
> $ make clean
> $ ls ../install/
> #  -- as expected
>
>
> 
>
> Any thoughts? Let me know if this is just a misunderstanding, if I
> should file a bug on this or if more information is needed.
>
> Best regards
>
> Hugo Heden
> Stockholm
> Sweden
>
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] INCLUDE_DIRECTORIES in sub-directories doesn't work?

[Hugo Heden]

2008/11/25 Sean Soria <[EMAIL PROTECTED]>:
> CMakeLists.txt:
> INCLUDE_DIRECTORIES(.)
> ADD_SUBDIRECTORY(foo)
> ADD_EXECUTABLE(hello main.c foo/main.c)
>

How about an absolute path instead of a relative?

INCLUDE_DIRECTORIES( ${CMAKE_CURRENT_SOURCE_DIR} )

> foo/CMakeLists.txt:
> INCLUDE_DIRECTORIES(.)
>
> I would expect foo/main.c to be compiled with:
> /usr/bin/gcc   -I/code/xbmc/XBMC/build.test/.
> -I/code/xbmc/XBMC/build.test/foo/.   -o
> CMakeFiles/hello.dir/foo/main.o   -c
> /code/xbmc/XBMC/build.test/foo/main.c
>
> I even see the include path defined in
> foo/CMakeFiles/CMakeDirectoryInformation.cmake:
> SET(CMAKE_C_INCLUDE_PATH
>  "."
>  "foo/."
>  )
>
> Unfortunately cmake seems to ignore these and I get this instead:
> /usr/bin/gcc   -I/code/xbmc/XBMC/build.test/.   -o
> CMakeFiles/hello.dir/foo/main.o   -c
> /code/xbmc/XBMC/build.test/foo/main.c
>
> Am I missing something or is INCLUDE_DIRECTORIES broken?  I've even
> tried set_property on the directory.
> ___
> CMake mailing list
> CMake@cmake.org
> http://www.cmake.org/mailman/listinfo/cmake
>
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Link in object files generated by another tool

[Hugo Heden]

2008/11/24 James Bigler <[EMAIL PROTECTED]>:
> Is it possible to link in an object file generated by another tool?
>
> I want to create a custom command that generates an object file that I
> could then link into a library or executable later.
>
> Is this possible from CMake?
>

An example follows. The ADD_CUSTOM_COMMAND that you may be looking for
is at the bottom.


SET( EXPAT_DIR_STRING expat-2.0.1 )

SET( expat_fpic_object_files
  ${CMAKE_CURRENT_BINARY_DIR}/${EXPAT_DIR_STRING}/lib/.libs/xmlparse.o
  ${CMAKE_CURRENT_BINARY_DIR}/${EXPAT_DIR_STRING}/lib/.libs/xmlrole.o
  ${CMAKE_CURRENT_BINARY_DIR}/${EXPAT_DIR_STRING}/lib/.libs/xmltok.o
)

ADD_LIBRARY(
  expat
  STATIC
  EXCLUDE_FROM_ALL
  ${expat_fpic_object_files}
)

SET_SOURCE_FILES_PROPERTIES(
  ${expat_fpic_object_files}
  PROPERTIES
  EXTERNAL_OBJECT true # to say that "this is actually an object file,
so it should not be compiled, only linked"
  GENERATED true   # to say that "it is OK that the obj-files do
not exist before build time"
  )

SET_TARGET_PROPERTIES(
  expat
  PROPERTIES
  LINKER_LANGUAGE C # Or else we get an error message, because cmake
can't figure out from the ".o"-suffix that it is a C-linker we need.
  ARCHIVE_OUTPUT_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/lib
  )


ADD_CUSTOM_COMMAND(
  OUTPUT
${expat_fpic_object_files}
  WORKING_DIRECTORY  
  COMMAND  # Some tool
  COMMAND  # Some tool
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Adding install dependency to test-target?

[Hugo Heden]

Eric Noulard wrote:

Good day all,


Is there any way that I can add 'install' dependency to the 'test'-target?

Doing

 add_dependencies( test install )

does not seem to work:
 CMake Error at ... (ADD_DEPENDENCIES):
add_dependencies Adding dependency to non-existent target: test


May be you can try to add a first "fake test" which does it:

ADD_TEST(00_Install ${CMAKE_BUILD_TOOL} install)
Aha, I did not think about that, that's very nice, thanks a lot Eric! 
(But for future reference, see below)



I don't think it's possible to add dependencies to "built-in" CMake target
(which deserve a feature request :-)
  
Ok, I'll file one (unless prompted not to, pending any future discussion 
here -- I don't really have a valid use-case!)




I realized that I don't really have a valid use-case for letting 'test' 
depend on 'install', and I think there could never be one.


Reasoning: In any context where it would be unsafe to invoke 'test' 
without 'install', one would want to do something like


add_dependencies( test install )

or, as Eric suggested,

ENABLE_TESTING()
# First test:
ADD_TEST(00_Install ${CMAKE_BUILD_TOOL} install)

But this will not work: The user (developer..) could always *select* 
tests using ctest -R from the command line, like


$ ctest -R Blabla

in which case the 'install' target will *not* be invoked before the 
tests. For this reason, each and every test must depend on that 
everything is installed (e.g each test could start with invoking 
${CMAKE_MAKE_PROGRAM} install) ..


Now, this is unfortunate, because checking that installation is 
up-to-date takes a bit of time.  And when _N_ tests are run, for example 
by invoking 'make test', this installation-is-up-to-date check is 
performed  _N-1_ times too many.


There are probably ways to resolve this.. but I haven't yet.

Ok, thanks for reading!

Best Regards
Hugo Heden



___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

[CMake] Adding install dependency to test-target?

[Hugo Heden]

Good day all,


Is there any way that I can add 'install' dependency to the 'test'-target?

Doing

 add_dependencies( test install )

does not seem to work:
  CMake Error at ... (ADD_DEPENDENCIES):
 add_dependencies Adding dependency to non-existent target: test


Apparently neither 'test' nor 'install' counts as "top-level-targets"?


Best regards

Hugo Heden
FOI -- Swedish Defence Research Agency

___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

[CMake] Bug? additional_clean_files not respected if no target present in directory

[Hugo Heden]

Good day all,

It seems that

   set_directory_propersties( properties additional_clean_files ... )

is not respected if no target present in the directory -- that is
'make clean' will not remove the specified "additional clean file".

Is this possibly a CMake bug, or is it rather a misunderstanding on my part?

$ cmake --version
cmake version 2.6-patch 2

A little test case to illustrate this follows. We have two
CMakeLists.txt-files, one in the root directory and one in a sub
directory.  The former (src/CMakeLists.txt) is not really important,
but included here for completeness. The latter,
src/subdir/CMakeLists.txt, is where the bug appears. There is also a
file that is being installed, src/subdir/hello.txt. Invoking 'make
clean' will not clean that file unless there is an actual target
specified in src/subdir/CMakeLists.txt.

File tree:.

|-- build
|-- install
`-- src
|-- CMakeLists.txt
`-- subdir
|-- CMakeLists.txt
`-- hello.txt


--- src/CMakeLists.txt:

CMAKE_MINIMUM_REQUIRED(VERSION 2.6)
SET( CMAKE_INSTALL_PREFIX ${CMAKE_SOURCE_DIR}/../install )

ADD_SUBDIRECTORY( subdir )

ADD_CUSTOM_TARGET(
  some_target
  COMMAND ${CMAKE_COMMAND} -E echo HELLO
)



--- src/subdir/CMakeLists.txt:

#ADD_CUSTOM_TARGET(
#  some_subdir_target
#  COMMAND ${CMAKE_COMMAND} -E echo WHOHOO
#)

INSTALL(
  FILES hello.txt
  DESTINATION ./
  )

SET_DIRECTORY_PROPERTIES(
  PROPERTIES
  ADDITIONAL_MAKE_CLEAN_FILES
  ${CMAKE_INSTALL_PREFIX}/hello.txt
  )

---
---

As written above, with the target "some_subdir_target" commented out,
the ADDITIONAL_MAKE_CLEAN_FILES will not be respected - - it seems to
be sort of optimized away:

$ cd build/
$ cmake ../src
...
...
$ make install
...
$ ls ../install
hello.txt
$ make clean
$ ls ../install/
hello.txt   # <--- OUCH





However, if the target is not commented out it will all work nicely:


--- src/subdir/CMakeLists.txt:

ADD_CUSTOM_TARGET(
  some_subdir_target
  COMMAND ${CMAKE_COMMAND} -E echo WHOHOO
)

INSTALL(
  FILES hello.txt
  DESTINATION ./
  )

SET_DIRECTORY_PROPERTIES(
  PROPERTIES
  ADDITIONAL_MAKE_CLEAN_FILES
  ${CMAKE_INSTALL_PREFIX}/hello.txt
  )





$ cd build/
$ cmake ../src
...
...
$ make install
...
$ ls ../install
hello.txt
$ make clean
$ ls ../install/
 #  -- as expected




Any thoughts? Let me know if this is just a misunderstanding, if I
should file a bug on this or if more information is needed.

Best regards

Hugo Heden
Stockholm
Sweden
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake