[cmake-developers] [CMake 0014181]: One-character function names don't work

[Mantis Bug Tracker]

The following issue has been SUBMITTED. 
== 
http://www.cmake.org/Bug/view.php?id=14181 
== 
Reported By:Wojciech Knapik
Assigned To:
== 
Project:CMake
Issue ID:   14181
Category:   CMake
Reproducibility:always
Severity:   minor
Priority:   low
Status: new
== 
Date Submitted: 2013-05-30 23:38 CEST
Last Modified:  2013-05-30 23:38 CEST
== 
Summary:One-character function names don't work
Description: 
$ cat CMakeLists.txt
function(a)
endfunction()
a()
$ cmake .
CMake Error: Error in cmake code at
/tmp/CMakeLists.txt:3:
Parse error.  Expected a command name, got unquoted argument with text "a".
-- Configuring incomplete, errors occurred!
$
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2013-05-30 23:38 Wojciech KnapikNew Issue
==

--

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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] Function overrides

[Wojciech Knapik]

On Thu, May 30, 2013 at 08:01:16PM +0200, Wojciech Knapik wrote:

> On Thu, May 30, 2013 at 11:39:01AM -0400, Brad King wrote:
> 
> > On 05/30/2013 11:14 AM, Wojciech Knapik wrote:
> 
> > > PS. I know you can achieve this by providing a wrapper for the user to
> > > use instead of the standard function, but that's not nearly as nice, is
> > > it ?

Since I'm likely not getting any further with the function overriding
issue, I'm thinking of other ways to do this, but they're all bad.

Let's say I'd like to write two unrelated modules, that provide some
functionality related to add_executable(). I could just provide a
function to call in addition to add_executable(). This would require
modifying all the CMakeLists calling that function and adding the call
to the one the module provides. That's not DRY, since I could just call
one function that calls the two. So, to remove this problem, I create a
wrapper in the module, that calls add_executable() and my function.
Let's call it add_foo_executable() (provided by module foo). So I edit
all the CMakeLists and substitute occurrences of add_executbale() with
add_foo_executable(). That could be hundreds of changes, but let's say
for now this is ok. Then I include the second module bar, that also
provides a function and a wrapper. I can't use the new wrapper, because
I already use the old one. I can't fuse the wrappers together, so the
only way out is to create a third wrapper outside both of these modules,
that calls add_executable() and the two functions provided by the two
modules. That sort of works, but now I have to edit all the CMakeLists
again and I've effectively coupled my code and the two modules together.
But let's say for now, that that's not wrong in any way.

A few months pass, a few more modules get written and it all turns out
to work quite nicely, so I decide to publish them as open source, for
everyone's benefit. How do I distribute these modules and allow people
to use any combination of them ? Do I create a separate wrapper for
every combination ? Do I create a series of if(COMMAND ...) in the one
wrapper ? Where do I define that wrapper ? If I put it in each of the
modules (wrapped in if(NOT COMMAND ...)), that's copy-pasting code, if I
create a third module with just that function, the modules are no longer
standalone.

There's no good way out of this.
Or I don't see one.
Which is it ?

> > As someone reading code I like knowing that a command does what the
> > CMake documentation says it does and nothing more.
> 
> I agree, that you shouldn't do this if you're changing the signature
> of the function, or any of the functionality described in the
> documentation. But if you're only using the original function as a
> "hook" to perform some additional action it seems totally acceptable
> to me. It provides a nice way to create "zeroconf" modules. And if
> things go sideways, the stack trace will make this case
> distinguishable from an error in the original function.
> 
> CMake does not provide any meta-programming facility, not even the
> simplest "eval" function, so it would be nice if at least this
> mechanism worked in a more generally useful way...

Ok, so is there a way to execute a piece of CMake code for every target,
or every CMakeList parsed ?

WK
--

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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] Time truncation bug in cmake -E touch

[Alan W. Irwin]

On 2013-05-30 08:28-0400 Brad King wrote:


On 05/30/2013 08:26 AM, Alan W. Irwin wrote:

To illustrate the problem on Linux:

wine@raven> touch test1; cmake -E touch test2; touch test3
wine@raven> ls -lrt --time-style=full-iso test[123]
-rw-r--r-- 1 wine wine 0 2013-05-30 04:18:25.0 -0700 test2
-rw-r--r-- 1 wine wine 0 2013-05-30 04:18:25.761281846 -0700 test1
-rw-r--r-- 1 wine wine 0 2013-05-30 04:18:25.765281683 -0700 test3

Note the time on test2 generated by cmake -E touch has been truncated to the 
nearest second so
it is not in the correct time order compared to test1 and test3.
I checked that both CMake-2.8.10.2 and CMake-2.8.0 had this issue
so it appears this is a bug that has been around for a while.


http://www.cmake.org/Bug/view.php?id=14020


Thanks for that link to an existing bug report on this issue.

I have put further notes there concerning using utimes (microsecond time
resolution which is still much better than the 1-second time resolution of
utime) to the mix when utimensat (nanosecond time resolution) is not
available.

Because this bug causes obvious file dependency issues for
ExternalProject_Add, I hope you are able to soon give this bug high
priority priority again rather than leaving it in its current state
(bugfix almost finished but backlogged).

Alan
__
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__

Linux-powered Science
__
--

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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] Function overrides

[Wojciech Knapik]

On Thu, May 30, 2013 at 11:39:01AM -0400, Brad King wrote:

> On 05/30/2013 11:14 AM, Wojciech Knapik wrote:
>
> > The problem is, that you can't redefine, say, add_executable more than
> > once, as discussed here:
> > http://www.cmake.org/pipermail/cmake/2011-March/043320.html
> 
> The command-override feature is meant for local debugging only.
> 
> Allowing "recursive" overrides is ill-defined because of the
> way functions are (not) scoped when the same module is included
> in multiple disjoint directories.

When you do:

function(add_executable)
message("A")
_add_executable(${ARGN})
endfunction()
function(add_executable)
message("B")
_add_executable(${ARGN})
endfunction()

you'd think that the "A" version of add_executable(), once parsed, would
be immutable, but defining the "B" version seems to change the meaning
off _add_executable() retroactively, affecting the "A" version.

I hate to say it again, but that is surprising ;-)

> > PS. I know you can achieve this by providing a wrapper for the user to
> > use instead of the standard function, but that's not nearly as nice, is
> > it ?
> 
> As someone reading code I like knowing that a command does
> what the CMake documentation says it does and nothing more.

I agree, that you shouldn't do this if you're changing the signature of
the function, or any of the functionality described in the
documentation. But if you're only using the original function as a
"hook" to perform some additional action it seems totally acceptable to
me. It provides a nice way to create "zeroconf" modules. And if things
go sideways, the stack trace will make this case distinguishable from an
error in the original function.

CMake does not provide any meta-programming facility, not even the
simplest "eval" function, so it would be nice if at least this mechanism
worked in a more generally useful way...

WK
--

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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] Safe source list GLOBs

[Jean-Christophe Fillion-Robin]

Hi Folks,

Being able to activate the dynamic globing on a per-directory or per-target
or per-glob call basis would be nice. Coupled with "automoc" feature of Qt,
that would simplify things greatly.

I would be happy to test patches on our large scale project "3DSlicer".
See https://github.com/Slicer/Slicer

Thanks
Jc


On Thu, May 30, 2013 at 11:50 AM, Matthew Woehlke <
matthew.woeh...@kitware.com> wrote:

> On 2013-05-30 08:47, Wojciech Knapik wrote:
>
>> Working with make taught me once and for all, that functions like
>> [execute_process] should be avoided whenever possible. A build tool
>>
>> creates files from files via the means of targets. So if you want to
>> use a tool like this effectively, you should use targets to achieve
>> your goals, otherwise unexpected things will happen.
>>
>
> That is true in most cases. However it is sometimes necessary, e.g. run
> some tool to get its version string (because that information is not
> otherwise available) in order to determine the correct install destination
> for some files.
>
> While add_custom_command is to be preferred in almost all cases, there are
> definitely correct uses for execute_process, usually similar to uses for
> e.g. try_compile (i.e. gathering system configuration information).
>
> (Most recently, I am using it to parse a Shiboken typesystem XML to
> determine the list of source files that will be created by binding
> generation in order to feed them to add_library. This would be impossible
> at build time short of using an external project.)
>
> --
> Matthew
>
>
> --
>
> 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://public.kitware.com/cgi-**bin/mailman/listinfo/cmake-**developers
>



-- 
+1 919 869 8849
--

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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

[cmake-developers] [CMake 0014180]: Add SYSTEM support to target_includ_directories

[Mantis Bug Tracker]

The following issue has been SUBMITTED. 
== 
http://public.kitware.com/Bug/view.php?id=14180 
== 
Reported By:mwoehlke
Assigned To:
== 
Project:CMake
Issue ID:   14180
Category:   CMake
Reproducibility:N/A
Severity:   feature
Priority:   normal
Status: new
== 
Date Submitted: 2013-05-30 12:25 EDT
Last Modified:  2013-05-30 12:25 EDT
== 
Summary:Add SYSTEM support to target_includ_directories
Description: 
It would be greate if target_include_directories (both for the direct target,
and propagated to subsequent users via target usage requirements) supported
marking include directories as SYSTEM. This is especially important when using
strict warnings-as-errors for compiling local code in the presence of
third-party (or even libc/stl) headers that trigger the same.

Additional Information: 
Offhand guess at the easiest way to implement this would be to recognize SYSTEM
and something else ('LOCAL'?) as keywords in the includes list to toggle if
include directories are marked as system or not.
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2013-05-30 12:25 mwoehlke   New Issue
==

--

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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] Safe source list GLOBs

[Matthew Woehlke]

On 2013-05-30 08:47, Wojciech Knapik wrote:

Working with make taught me once and for all, that functions like
[execute_process] should be avoided whenever possible. A build tool
creates files from files via the means of targets. So if you want to
use a tool like this effectively, you should use targets to achieve
your goals, otherwise unexpected things will happen.


That is true in most cases. However it is sometimes necessary, e.g. run 
some tool to get its version string (because that information is not 
otherwise available) in order to determine the correct install 
destination for some files.


While add_custom_command is to be preferred in almost all cases, there 
are definitely correct uses for execute_process, usually similar to uses 
for e.g. try_compile (i.e. gathering system configuration information).


(Most recently, I am using it to parse a Shiboken typesystem XML to 
determine the list of source files that will be created by binding 
generation in order to feed them to add_library. This would be 
impossible at build time short of using an external project.)


--
Matthew

--

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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] Function overrides

[Brad King]

On 05/30/2013 11:14 AM, Wojciech Knapik wrote:
> The problem is, that you can't redefine, say, add_executable more than
> once, as discussed here:
> http://www.cmake.org/pipermail/cmake/2011-March/043320.html

The command-override feature is meant for local debugging only.

Allowing "recursive" overrides is ill-defined because of the
way functions are (not) scoped when the same module is included
in multiple disjoint directories.

> PS. I know you can achieve this by providing a wrapper for the user to
> use instead of the standard function, but that's not nearly as nice, is
> it ?

As someone reading code I like knowing that a command does
what the CMake documentation says it does and nothing more.

-Brad
--

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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] INTERFACE_LINK_LIBRARIES property?

[Brad King]

On 05/30/2013 10:50 AM, Stephen Kelly wrote:
> I'm not convinced that a policy to disallow the old and new signatures 
> together is actually better though. It preserves the historical behavior 
> even if the policy is NEW, and will be a bit confusing for anyone attempting 
> to use a new signature with a LHS target, especially if the new signature is 
> already in use elsewhere in the project or file ('It works with foo, why 
> doesn't it work with bar in the same file?!?').

* The error (or warning when policy is not set) message should list all
  call sites along with which signature they use and explain that they
  need to be made consistent.  Currently the tll() docs for the old
  signature warn that the new signature can "break" the public interface.

* The signature policy setting should be queried at each call site rather
  than recorded when the target is created.

> For anyone hitting issues like those, it will make sense at that point to 
> port everything to the new signature anyway for maintenance

Yes, and the signature policy's message can help with doing that.

> In spite of the above, I can agree to that in the interest of moving along 
> and getting some new consistent signatures in place.

That is my goal also.  My "signature policy" proposal is motivated by:

(1) The old signatures make sense on their own.
Lots of projects use them.  They are not "wrong".

(2) The new signatures make sense on their own.
They have better shared library interface defaults.

(3) Combinations of old and new signatures produce confusing results

Policies are intended for use when a new behavior is clearly superior
to the old behavior.  Both (1) and (2) are fine individually, even with
INTERFACE_LINK_LIBRARIES.  It is the behavior in (3) that is bad and
making old/new signatures exclusive is clearly superior.

>> I wonder if we can distinguish PUBLIC/PRIVATE/INTERFACE for STATIC
>> for application of usage requirements.  The requirement to link
>> dependents to a static library's dependencies is an implementation
>> detail for linking only.
> 
> Something like this will probably be possible. I'll have a closer look at 
> the implementation later.

Great, thanks.

-Brad
--

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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

[cmake-developers] Function overrides

[Wojciech Knapik]

Hi

I want to write several self-contained modules that would each hijack a
standard CMake function in order to execute some CMake code when
necessary, without requiring the user to alter their existing
CMakeLists.

The idea is that including the module will provide functionality with no
other actions required.

The problem is, that you can't redefine, say, add_executable more than
once, as discussed here:
http://www.cmake.org/pipermail/cmake/2011-March/043320.html

Is there a way to achieve this, one way, or another ?

I actually have two use cases here - one is where I want to redefine
add_executable/add_library specifically and the other is where I don't
really want to redefine anything, but I need to execute a piece of code
in every CMakeList in the project.

thanks,
WK

PS. I know you can achieve this by providing a wrapper for the user to
use instead of the standard function, but that's not nearly as nice, is
it ?
--

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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

[cmake-developers] [CMake 0014178]: Eclipse CDT Generator uses fixed CPU Count for parallel build

[Mantis Bug Tracker]

The following issue has been SUBMITTED. 
== 
http://www.cmake.org/Bug/view.php?id=14178 
== 
Reported By:nob
Assigned To:
== 
Project:CMake
Issue ID:   14178
Category:   CMake
Reproducibility:always
Severity:   tweak
Priority:   normal
Status: new
== 
Date Submitted: 2013-05-30 10:51 EDT
Last Modified:  2013-05-30 10:51 EDT
== 
Summary:Eclipse CDT Generator uses fixed CPU Count for
parallel build
Description: 
When using the Eclipse CDT4 (Unix Makefiles) Generator, CMake always generates a
parallel build. While this is a generally a good idea, the number of CPUs may be
to high on some projects/systems.

Here I have a Core i7 4-Core Laptop, where the ProcessorCount module reports 8
Processors. Using a parallel build with "make -j8", all compile jobs eat up all
available RAM of the system, making it unusable.

It would be nice if the number parallel job count could be configurable and just
falls back to the number ProcessorCount reproduces.

Steps to Reproduce: 
- Use Eclipse CDT4 - Unix Makefiles Generator
- In Eclipse, look into Project/Properties/C/C++-Make Project/Make Builder -->
Build command has a fixed "-j" argument which seems not configureable.

On each reinvocation of cmake, the parallel job number is set back to its
default.


== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2013-05-30 10:51 nobNew Issue
==

--

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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

[cmake-developers] [CMake 0014179]: FindBoost does not treat paths properly

[Mantis Bug Tracker]

The following issue has been SUBMITTED. 
== 
http://public.kitware.com/Bug/view.php?id=14179 
== 
Reported By:azdagron
Assigned To:
== 
Project:CMake
Issue ID:   14179
Category:   Modules
Reproducibility:always
Severity:   major
Priority:   normal
Status: new
== 
Date Submitted: 2013-05-30 10:52 EDT
Last Modified:  2013-05-30 10:52 EDT
== 
Summary:FindBoost does not treat paths properly
Description: 
I set my CMAKE_PREFIX_PATH, to a folder on my C: drive (c:\work) as well as
setting CMAKE_LIBRARY_PATH, BOOST_INCLUDEDIR and BOOST_LIBRARYDIR to folders
within that path (i.e. c:\work\include and c:\work\lib).

I then do a find_package(Boost 1.53.0 ...) and it tries to escape the \w from
c:\work and fails.

This works fine with CMake 2.8.10.2.
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2013-05-30 10:52 azdagron   New Issue
==

--

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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] INTERFACE_LINK_LIBRARIES property?

[Stephen Kelly]

Brad King wrote:

> Steve,
> 
> I think we're pretty close to agreement here!
> 
> On 05/30/2013 05:31 AM, Stephen Kelly wrote:
>>> This will give projects a choice on whether they want to populate the
>>> old properties explicitly or ask CMake to do it for them.
>> 
>> Rather than offer so much choice for something which is pure backwards-
>> compatibility (and therefore obsolete from the start), I'd prefer to
>> offer only one way - user specified old properties.
> 
> Okay.  This capability is only needed when a package requires a new CMake
> itself but wants to support consumers with older CMake versions.  I expect
> this is not such an important use case.  

Agreed.

> Let's go with the user-specified
> old properties for optional export when the policy is NEW, as you propose.
> 
>> This seems very similar to the proposal I made ('I'd propose deprecating
>> with a policy the signature...') that you vetoed. Is it just a refinement
>> of what I proposed?
> [snip]
>> Yes, I think this is also what I proposed.
> 
> Yes, it is fair to call my proposal a refinement of yours.  I read yours
> to mean disallowing the old signature altogether.  Mine is to disallow use
> of old and new signatures together.

Ah, that's what I missed from your email, and the critical difference. 
Indeed, what I proposed was to disallow the old signature altogether with 
the policy. 

I'm not convinced that a policy to disallow the old and new signatures 
together is actually better though. It preserves the historical behavior 
even if the policy is NEW, and will be a bit confusing for anyone attempting 
to use a new signature with a LHS target, especially if the new signature is 
already in use elsewhere in the project or file ('It works with foo, why 
doesn't it work with bar in the same file?!?'). Seen the other way, for a 
target which uses the new signature, someone reading internet/docs/tutorials 
and seeing the old signature will not be able to use it, if the policy is 
NEW. 

For anyone hitting issues like those, it will make sense at that point to 
port everything to the new signature anyway for maintenance

> That way the historical behavior will
> continue to work without any warnings or errors but projects can choose to
> use the new signature exclusively to get preferred behavior.

In spite of the above, I can agree to that in the interest of moving along 
and getting some new consistent signatures in place.

>> Although I still propose deprecating LINK_PUBLIC/LINK_PRIVATE for
>> PUBLIC/PRIVATE for consistency with the new commands.
> 
> This is fine, but I'd rather not produce any warnings for the LINK_
> versions and just allow projects to use either.  We can recommend the
> latter in documentation.

Ok. Let's see how that fits together with the rest of the issues.

> We need to update this for the lack of tui().  Whatever behavior we
> define for STATIC libraries needs to make sense when used like this:
> 
>  add_library(foo foo.c) # SHARED or STATIC based on BUILD_SHARED_LIBS
>  target_link_libraries(foo PUBLIC a PRIVATE b INTERFACE c)
> 
> I wonder if we can distinguish PUBLIC/PRIVATE/INTERFACE for STATIC
> for application of usage requirements.  The requirement to link
> dependents to a static library's dependencies is an implementation
> detail for linking only.  Therefore we do not need to propagate the
> other usage requirements (defines, includes) for private dependencies
> of a static library.  I think we can populate the LINK_LIBRARIES and
> INTERFACE_LINK_LIBRARIES for static libraries the same as shared, and
> just teach the link logic to use LINK_LIBRARIES for transitive *link*
> behavior of static libraries but not for other usage requirements.

Something like this will probably be possible. I'll have a closer look at 
the implementation later.

Thanks,

Steve.


--

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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] Safe source list GLOBs

[Brad King]

Hi Folks,

Putting on my list moderation hat, I'd like to terminate the debate
in this thread.  Arguments on both sides have been hashed out a few
times.  Whether we all agree or not, some people find source globs
useful and it will not be disruptive to CMake to add an option to
add dependencies on the source directories to enable re-globbing.

On 05/13/2013 09:49 AM, Brad King wrote:
> This would be much better done as a change to CMake's implementation.
> We already generate a rule to re-run CMake when CMakeLists.txt and
> other files read by CMake change.  One could add an option to add
> directories to the dependencies of that rule too.  Look for the
> AddCMakeDependFile method for example.  If you go this route please
> post a proposed interface here first before diving into the effort
> of a patch.

I've outlined a method to achieve the requested effects.  Now we
just need a volunteer with time, interest, and capability to implement
it.  If you don't want to use the feature then you do not have to be
that volunteer.  When a volunteer comes along I will not reject the
patch based solely on debate of the feature's value (but may for other
technical details of the implementation as appropriate).

-Brad
--

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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] Safe source list GLOBs

[Wojciech Knapik]

On Thu, May 30, 2013 at 08:27:28AM +0200, Michael Wild wrote:

> Also, very astonishing to me is the fact that after apparently finding
> file(GLOB) in the documentation, you clearly didn't read the whole
> paragraph. It's right there:
> 
> >> We do not recommend using  GLOB  to collect  a list of source files
> >> from your source tree.  If no CMakeLists.txt file changes when a
> >> source is added or removed then the generated build system cannot
> >> know when to ask CMake to regenerate.
> 
> As you are so fond of clear violations: You failed to RTFM...
> (http://en.wikipedia.org/wiki/Rtfm)

Have you ever assumed, when crossing a street you know very well, that
cars will only come from one side and neglected to look in the other
direction ?

I needed a function to glob, I read the signature and went on to use it.

I did notice that in the documentation later.

> Besides, you seem to be very sure that CMake is the *only* tool that
> prefers explicit source file listing. 

Nope.

> Have you ever used any of the popular IDE's? Visual Studio? Xcode?
> Eclipse? They all create explicit list of files in their projects.

An IDE is a different class of tool, that builds on top of tools such as
CMake. Apples and oranges.

> What are the (not so serious) pros and cons of GLOB, even if it worked
> the way you think it should?
> 
> Pro:
> * laziness

You say it, like it's a bad thing.

> Con:
> * laziness
> * extremely error prone:
>   - picks up scratch files
>   - works for you but breaks for others because you forgot to commit a
> file
>   - breaks for you because the other dude forgot to commit his file
> * makes it unnecessarily difficult to exclude files from the build
>   - temporarily: for testing (you'd need to move the file away and then
> remember to move it back; error prone again)
>   - permanently: dependent on the platform, configuration, enabled
> capabilities etc. And using #ifdef's for this is bad because you
> still invoke the compiler and waste time to just compile an "empty"
> file.
> * when reading the build system code, you have to switch context in
>   order to determine the files included in the build.

We've been through all these points earlier in this thread.

> On the other hand, initially creating and then maintaining an explicit
> list of files is easy. Initially I usually create the list of files like
> this using vim:
> 
> :r !cd $(dirname %); ls **/*.{c,cpp}; ls **/*.{h,hpp}

It's not about the difficulty of creating a file list.

WK
--

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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] Safe source list GLOBs

[Wojciech Knapik]

On Wed, May 29, 2013 at 04:59:22PM -0400, Matthew Woehlke wrote:

> On 2013-05-28 21:23, Wojciech Knapik wrote:
>
> > On Fri, May 24, 2013 at 11:21:57AM -0400, Matthew Woehlke wrote:
> >
> >> GLOB is just one of many things that will surprise you when working with
> >> CMake if you don't understand the difference between the configure and
> >> build passes.
> >
> > I've written quite a bit of CMake code in the past 6 months and so far
> > that's the only thing that really surprised me.
> 
> execute_process? That's at least the main other one I always have to be 
> careful about.

Working with make taught me once and for all, that functions like this
should be avoided whenever possible. A build tool creates files from
files via the means of targets. So if you want to use a tool like this
effectively, you should use targets to achieve your goals, otherwise
unexpected things will happen.

> > I do understand the distinction between calling cmake and make and I
> > understood from the start when variables are evaluated and such, but I
> > just assumed that globs are propagated to the generated build system,
> > because a) why not ? b) what's the point of globs if they aren't ?
> >
> > Imagine my surprise...
> 
> Actually, I find your surprise very surprising. You say you understand 
> that setting and using variables happens at configure time. Well, 
> file(GLOB) populates a variable... so why would you expect those 
> variables to be somehow magically special?

Come to think of it, you're completely right. I can easily imagine a
case where you want to execute some CMake code for, say, every file
globbed. That would require re-running cmake. It just didn't occur to me
until much later.

> > I don't think we need to be concerned about adding a few miliseconds to
> > a no-op build, even if that constitutes a major percentage increase.
> 
> If that was true (and *especially* if the relative cost was 
> non-trivial), ninja probably would not exist. These things add up... a 
> few ms here, a few ms there, and suddenly it takes many seconds to build 
> even a moderately large project set, that could otherwise be built in 
> barely a second (if that). For that matter, even if it made a difference 
> of 'only' 100 ms (say, in something the size of VTK), I would consider 
> that a lot.

s/ms/ns/ if you consider caching.

But like I said:
a) You know where globs are used and you can only re-expand them for
those directories, so if no globs are used, the penalty is next to
nothing
b) The option to re-expand the globs could be turned off by default

> As previously stated, there are really only two ways to do this 
> correctly. One is to just always re-run CMake, which is unacceptable for 
> any project of more than trivial size. The other is to teach CMake to 
> reevaluate its globs and reevaluate if it needs to reconfigure. If this 
> is even *possible* across build managers, it is probably not easy, but 
> if you want to write a patch for that, I feel confident it will be 
> considered.

Like I wrote in the previous email - I'm happy to provide CMake code, or
code in several other languages, but I'm afraid C++ is not one of them.

WK
--

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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] Time truncation bug in cmake -E touch

[Brad King]

On 05/30/2013 08:26 AM, Alan W. Irwin wrote:
> To illustrate the problem on Linux:
> 
> wine@raven> touch test1; cmake -E touch test2; touch test3
> wine@raven> ls -lrt --time-style=full-iso test[123]
> -rw-r--r-- 1 wine wine 0 2013-05-30 04:18:25.0 -0700 test2
> -rw-r--r-- 1 wine wine 0 2013-05-30 04:18:25.761281846 -0700 test1
> -rw-r--r-- 1 wine wine 0 2013-05-30 04:18:25.765281683 -0700 test3
> 
> Note the time on test2 generated by cmake -E touch has been truncated to the 
> nearest second so
> it is not in the correct time order compared to test1 and test3.
> I checked that both CMake-2.8.10.2 and CMake-2.8.0 had this issue
> so it appears this is a bug that has been around for a while.

http://www.cmake.org/Bug/view.php?id=14020

-Brad
--

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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] INTERFACE_LINK_LIBRARIES property?

[Brad King]

Steve,

I think we're pretty close to agreement here!

On 05/30/2013 05:31 AM, Stephen Kelly wrote:
>> This will give projects a choice on whether they want to populate the
>> old properties explicitly or ask CMake to do it for them.
> 
> Rather than offer so much choice for something which is pure backwards-
> compatibility (and therefore obsolete from the start), I'd prefer to offer 
> only one way - user specified old properties.

Okay.  This capability is only needed when a package requires a new CMake
itself but wants to support consumers with older CMake versions.  I expect
this is not such an important use case.  Let's go with the user-specified
old properties for optional export when the policy is NEW, as you propose.

> This seems very similar to the proposal I made ('I'd propose deprecating 
> with a policy the signature...') that you vetoed. Is it just a refinement of 
> what I proposed?
[snip]
> Yes, I think this is also what I proposed.

Yes, it is fair to call my proposal a refinement of yours.  I read yours
to mean disallowing the old signature altogether.  Mine is to disallow use
of old and new signatures together.  That way the historical behavior will
continue to work without any warnings or errors but projects can choose to
use the new signature exclusively to get preferred behavior.

> Although I still propose deprecating LINK_PUBLIC/LINK_PRIVATE for
> PUBLIC/PRIVATE for consistency with the new commands.

This is fine, but I'd rather not produce any warnings for the LINK_
versions and just allow projects to use either.  We can recommend the
latter in documentation.

One thing I left out of my last response was the behavior for STATIC
libraries.  Here is what I said in the older thread:

On 12/22/2012 10:22 AM, Brad King wrote:
> For STATIC libraries the target_use_interfaces command
> PRIVATE/INTERFACE keywords still make sense because there could
> be different -I/-D for the implementation versus the interface.
> Only linking must be PUBLIC always.  For STATIC libraries we can
> define that the PUBLIC/PRIVATE/INTERFACE keys are ignored for
> linking and that it always populates both LINK_LIBRARIES
> LINK_INTERFACE_LIBRARIES.  Note that for STATIC libraries the
> LINK_LIBRARIES property will not be used for anything except
> build-order dependencies.  Unlike the old LINK_INTERFACE_LIBRARIES
> the new INTERFACE_LINK_LIBRARIES will be used for static libs too.
> That way projects can deal with the link interface for all targets
> in the same way.

We need to update this for the lack of tui().  Whatever behavior we
define for STATIC libraries needs to make sense when used like this:

 add_library(foo foo.c) # SHARED or STATIC based on BUILD_SHARED_LIBS
 target_link_libraries(foo PUBLIC a PRIVATE b INTERFACE c)

I wonder if we can distinguish PUBLIC/PRIVATE/INTERFACE for STATIC
for application of usage requirements.  The requirement to link
dependents to a static library's dependencies is an implementation
detail for linking only.  Therefore we do not need to propagate the
other usage requirements (defines, includes) for private dependencies
of a static library.  I think we can populate the LINK_LIBRARIES and
INTERFACE_LINK_LIBRARIES for static libraries the same as shared, and
just teach the link logic to use LINK_LIBRARIES for transitive *link*
behavior of static libraries but not for other usage requirements.

-Brad
--

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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

[cmake-developers] Time truncation bug in cmake -E touch

[Alan W. Irwin]

To illustrate the problem on Linux:

wine@raven> touch test1; cmake -E touch test2; touch test3
wine@raven> ls -lrt --time-style=full-iso test[123]
-rw-r--r-- 1 wine wine 0 2013-05-30 04:18:25.0 -0700 test2
-rw-r--r-- 1 wine wine 0 2013-05-30 04:18:25.761281846 -0700 test1
-rw-r--r-- 1 wine wine 0 2013-05-30 04:18:25.765281683 -0700 test3

Note the time on test2 generated by cmake -E touch has been truncated to the 
nearest second so
it is not in the correct time order compared to test1 and test3.
I checked that both CMake-2.8.10.2 and CMake-2.8.0 had this issue
so it appears this is a bug that has been around for a while.

It turns out the problem is in kwsys/SystemTools.cxx where utime is
used to update the file access and modification times.  Turns out
utime is obsolete and is only good to nearest second which is the
source of the "cmake -E touch" problem.  The library function utimes
should be used instead.

According to the man page

utime conforms to SVr4, POSIX.1-2001 while utimes conforms to 4.3BSD,
POSIX.1-2001.  So I don't think access to utimes will be an issue on
Unix.  According to http://www.mkssoftware.com/docs/man3/utimes.3.asp
it is available for Microsoft Windows as well (at least for
the NTFS filesystem).

Any chance for a quick fix without going through bug triage?

Errors of a second can be serious since they allow lots to happen out of order 
in Makefiles such
as the ExternalProject_Add_Step issue I discussed recently on the cmake list.

In particular this bug makes the ExternalProject_Add_Step problematic
when combined with add_custom_command OUTPUT results that are accessed
by the DEPENDS since those OUTPUT results are created with the correct 
untruncated
times and the timestamps are created by cmake -E touch (i.e., with
truncated times as above) which are out of order relative to the OUTPUT
results.  This ends up generating unnecessary builds.

ExternalProject_Add also systematically uses truncated time stamps
which means two different steps can have the same time for the
time stamp files.  Which will likely also lead to unnecessary rebuilds
if a step requires significantly less than a second to complete.

Alan
__
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__

Linux-powered Science
__
--

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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] Safe source list GLOBs

[Wojciech Knapik]

On Wed, May 29, 2013 at 04:55:33PM -0400, Matthew Woehlke wrote:

> On 2013-05-28 19:50, Wojciech Knapik wrote:
>
> > Files don't just happen to be lying around in directories. You have to
> > create them in a specific path, with a specific name. Even if the act of
> > creation was performed by another developer, on another machine, that
> > information is written to disk in the course of a VCS checkout.
> 
> IOW, you are claiming that *the VCS* is authoritative. (Personally I 
> would claim, at least as things stand now, that CMakeLists.txt is 
> authoritative, and any discrepancies with the files on disk represent 
> mistakes.)

The VCS client only writes files to a filesystem. What's on disk is your
underlying reality. The file listing in a CMakeList represents either
a) A 1-to-1 copy of what's on the filesystem, or
b) A modified version of that

If you choose to go with option a), an explicit file listing is
redundant, with all the consequences.
If you choose option b), an explicit file listing may be a better fit.

What I'm arguing, is that option a) is a legitimate choice and should be
possible without the redundant file list in a CMakeList.

> > The contents of the directory rules. If you remove a file from it,
> > there's nothing you can do in a CMakeList to help it. If you add a file
> > to it and you use GLOBs, there's nothing that you need to do in a
> > CMakeList for it to be built. (*)
> 
> In practice, developers *are* going to create 'scratch' files in source 
> directories. 

Like I wrote before - dot files will not be picked up by even the most
general globs, making it perfectly safe to combine globs and scratch
files. Just call your scratch file .foo.cpp instead of foo.cpp and all
will be fine.

> Or forget to add new files when committing.
> In the latter case, at least having CMakeLists.txt specifically ask for 
> the file will make it much more immediately obvious when this mistake 
> happens.

Should CMake be optimized for building proper commits, or broken ones ?
As of now, even if I never make mistakes while committing my code, I
can't use all files matching a glob to build a target, without
introducing redundancy to my build system. That, to me, seems like
optimizing for a corner case at the cost of an arguably common one.

> If there were a way to ask *the VCS* for the file list, I could see that 
> being useful; it would avoid the problem with 'scratch' files, and would 
> also help prevent forgetting to add files (since the developer would get 
> broken functionality at least until staging the addition). But of course 
> this would need to degrade gracefully when dealing with release 
> tarballs. (Ideally the release tarball would use an explicit list.)

Magic like this is fine in an IDE, not in a build system. A build system
should be VCS-agnostic IMO.
Whether you do `svn co', or `svn export', or just get a tarball from a
colleague, the build system should work the same. When your project
switches to a different VCS, that should not require changing the build
system in any way.

> Having an explicit list also helps guard against accidental deletion by 
> requiring an explicit change when a file should no longer be part of the 
> build. Using the VCS's expected file list could also serve this purpose, 
> but this would be another argument for at least source tarballs to use 
> explicit lists.

Yes, an explicit list would make such a problem visible more quickly.
But again - that's an optimization geared towards broken commits, at the
cost of a legitimate use case, where no mistakes were made while
committing.

> > What's the point of GLOBs anyway if you only reliably expand them once ?
> 
> I have often thought that GLOB is more dangerous than useful :-). 
> (Especially as I can't think of having ever used it.)

To each their own.
Just don't set(CMAKE_DYNAMIC_GLOBS TRUE) ;-)

> > Who wants a snapshot of the past state of a location on disk in a build
> > system ?
> 
> They're potentially useful for operations performed at configure time, 
> at which point they are current. If you're persisting them into the 
> build rules without some way of checking if they are still correct, then 
> you're doing it wrong :-).

That's the way it is now if you use globs with no mechanism to re-expand
them when necessary. That's what I'd like to see changed.

> >> People who are not used to CMake (perhaps) don't realize that when you
> >> edit a CMakeLists file, or any of its inputs, the expectation is that
> >> simply typing "make" will do a build, re-running cmake as needed, and
> >> only when needed.
> >
> > What's so special about CMake, that it's ok for you guys to break that
> > principle, but not ok for others ?
> 
> Really? Autotools is the same way (except I think they just break when 
> the autotools chain needs to be re-run, rather than trying to make it 
> happen automagically).

It's an obvious comparison (with autotools), true, but a bad point of
reference IMO ;]

> To some extent, 

Re: [cmake-developers] INTERFACE_LINK_LIBRARIES property?

[Stephen Kelly]

Brad King wrote:

> On 05/10/2013 06:41 AM, Stephen Kelly wrote:
>> * http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/5680
>>   (New INTERFACE_LINK_LIBRARIES policy approach)
> 
> I remember being quite happy with the proposal I made at the start of
> that thread.  Let's see if we can come up with something equivalent.
> For reference, the key sections of my message were:
> 
> On 12/22/2012 10:22 AM, Brad King wrote:
>> First I'll define how the properties behave when building a target.
>> I'll cover exporting below.
>>
>> In the OLD behavior the link interface is completely determined as
>> it is in CMake 2.8.10 by the LINK_INTERFACE_LIBRARIES(_)
>> properties.  The target_link_libraries command will populate the
>> properties as it does now and leave the new names untouched.
>>
>> In the NEW behavior the link interface is completely determined
>> by the new INTERFACE_LINK_LIBRARIES property.  All forms of tll()
>> including its LINK_INTERFACE_LIBRARIES mode will populate only
>> the new properties.  The old property is completely ignored.

Any thoughts on adding PUBLIC PRIVATE and INTERFACE keywords to tll for 
consistency with the other target_* commands?

 
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/6864/focus=6886

>> When the policy is not set (internally it is WARN) then tll()
>> will populate both the old and new properties.  ComputeLinkInterface
>> will compute both the old and new style link interfaces, warn if
>> they are different, and use the old one.

Ok.

> ...
>> Now, on to exporting.  Unlike the previous iteration the policy
>> affects it too.
>>
>> When the policy is OLD/WARN we export only the old interface and
>> not the new interface.
>>
>> When the policy is NEW we export only the new interface and not
>> the old interface by default.  We can have a new property to
>> explicitly request that the old link interface properties be
>> exported.  We can either ask projects to set the old interface
>> properties manually for export or try to compute the values from
>> the new ones by pre-evaluating the generator expressions for
>> each configuration.  This will allow projects to support older
>> CMake versions for their clients if they want to, but it will
>> be an explicit decision.

Yes.

> Now, returning to your message:
> 
> On 05/10/2013 06:41 AM, Stephen Kelly wrote:
>> If the new property is introduced, the behavior would be:
>> 
>> * If an in-buildsystem or IMPORTED target has the new property, it is
>> used
>>   and the old properties are not used.
> 
> For in-build targets this needs to depend on the policy setting as in my
> quote above.  The behavior of the project's build should not depend on
> the version of CMake currently running, but rather the behavior intended
> by the project author.  The intention is implied by the policy setting
> or lack of one.

Right.

> For IMPORTED targets I think your proposal is correct: use the new
> property if it is set and otherwise use the old property.  It is up to
> the provider of the imported targets to specify the old and/or new
> properties correctly to handle various CMake versions for consumers.

Right.

>> * When a target is install(EXPORT)ed, the new property will be exported.
> 
> ...when the policy is NEW.  When it is OLD/WARN we export only the old
> properties.

Ok.

>> ** There needs to be a way to determine whether to additionally export
>> the
>>old properties. Even if the exporting target does not have the old
>>properties set, we can still conditionally write the content of the
>>new INTERFACE_LINK_LIBRARIES to IMPORTED_LINK_INTERFACE_LIBRARIES, as
>>both now support generator expressions. This will allow exporting
>>projects to maintain compatibility with downstreams using CMake 2.8.11
>>(or earlier if generator expressions are not used).
> 
> Yes, and the install(EXPORT) option you proposed can work for that.
> If possible I'd like to try to (partially) evaluate the $-type
> expressions to set the old per-config properties.  That will make it easy
> for packages to support the old properties for CMake < 2.8.11.

I'm still not a fan of partial evaluation like that. It would be complex and 
a source of bugs for little gain.

>> ** If the old properties and the new property are set, we export them
>>all. This will allow exporting projects to maintain compatibility with
>>downstreams using CMake < 2.8.11. It is ok if the new
>>INTERFACE_LINK_LIBRARIES and the old LINK_INTERFACE_LIBRARIES have
>>differing content and no warning is issued. The new property may
>>simply contain new genex-powered-convenience, similar to how QtCore
>>now conveniently links to the qtmain.lib now on Windows.
> 
> Perhaps whatever install(EXPORT) option exports the old properties can
> also somehow indicate whether to use the project's settings for the old
> properties or try to generate values automatically from the new ones.

I'd prefer not to try to magically 

Re: [cmake-developers] Safe source list GLOBs

[Alexander Neundorf]

On Wednesday 29 May 2013, Matthew Woehlke wrote:
> On 2013-05-28 19:50, Wojciech Knapik wrote:
> > Files don't just happen to be lying around in directories. You have to
> > create them in a specific path, with a specific name. Even if the act of
> > creation was performed by another developer, on another machine, that
> > information is written to disk in the course of a VCS checkout.
> 
> IOW, you are claiming that *the VCS* is authoritative. (Personally I
> would claim, at least as things stand now, that CMakeLists.txt is
> authoritative, and any discrepancies with the files on disk represent
> mistakes.)
> 
> ...which (see more below) is actually an interesting idea.
> 
> > The contents of the directory rules. If you remove a file from it,
> > there's nothing you can do in a CMakeList to help it. If you add a file
> > to it and you use GLOBs, there's nothing that you need to do in a
> > CMakeList for it to be built. (*)
> 
> In practice, developers *are* going to create 'scratch' files in source
> directories. Or forget to add new files when committing.
> 
> In the latter case, at least having CMakeLists.txt specifically ask for
> the file will make it much more immediately obvious when this mistake
> happens.
> 
> If there were a way to ask *the VCS* for the file list, I could see that
> being useful; it would avoid the problem with 'scratch' files, and would
> also help prevent forgetting to add files (since the developer would get
> broken functionality at least until staging the addition). But of course
> this would need to degrade gracefully when dealing with release
> tarballs. (Ideally the release tarball would use an explicit list.)


The "Projects" plugin of the kate editor does something like that, it can ask 
svn, git and hg (I think) for the list of files and uses them as "project-
files", which are used e.g. when searching (i.e. this is unrelated to 
building).

Still, also ignoring the tarball case, this is not usable if you have more 
than one target in a directory, you explicitely have to list which file 
belongs where.

Alex
--

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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers