Re: [CMake] Unity builds (was: Re: [ANNOUNCE] CMake 3.16.0-rc1 is ready for testing)

[Paul Smith]

On Sat, 2019-10-12 at 19:25 -0700, Alan W. Irwin wrote:
> > Virtually all my properties are set on a per-target basis, so I assumed
> > they wouldn't be an issue here.
> > 
> > Am I misunderstanding that?
> 
> I think the current documentation is ambiguous about this.  But
> certain target and directory properties can affect the flags used to
> compile the source code just as much as source code properties.  So I
> am virtually positive the implementation has to pay attention to all
> these sources of properties to decide what can/cannot be lumped into a
> Unity source file.  If Kyle confirms this guess, then the
> documentation should be changed accordingly to remove the ambiguity
> about this.

I know no more than you but I'm quite sure that it's not the case that
adding library/executable-level options can cause unity to be disabled.
I've never heard of _ANY_ such target that didn't have at least some
properties defined for it.

A unity source file can lump together N real source files from the same
target (library/executable) as long as those files don't have extra
source-specific flags, because all other files in a given target have
the same flags.

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] Unity builds (was: Re: [ANNOUNCE] CMake 3.16.0-rc1 is ready for testing)

[Paul Smith]

On Fri, 2019-10-11 at 10:17 -0400, Kyle Edwards wrote:
> On Fri, Oct 11, 2019 at 1:36 AM Alan W. Irwin
> <
> alan.w.irwin1...@gmail.com
> > wrote:
> > The source files that have COMPILE_OPTIONS, COMPILE_DEFINITIONS,
> > COMPILE_FLAGS, or INCLUDE_DIRECTORIES will also be skipped."
> 
> This is by far the most likely reason. We added this restriction
> because we don't want files that have different COMPILE_FLAGS etc. to
> be lumped together in a unity file. We decided that this was good
> enough as a first past, but the way forward is to intelligently group
> together files that have the same COMPILE_OPTIONS,
> COMPILE_DEFINITIONS, COMPILE_FLAGS, and INCLUDE_DIRECTORIES.

I saw this in the manual, and I interpreted it to mean that if we used
something like set_source_files_properties() or set_property(SOURCE) to
set these properties on specific source files, then those files which
are impacted by this won't be part of unity builds.

That seems quite sensible to me.

However, I don't do that hardly anywhere at all; maybe one or two files
have an extra INCLUDE_DIRECTORIES setting or similar.

Virtually all my properties are set on a per-target basis, so I assumed
they wouldn't be an issue here.

Am I misunderstanding that?

It's also possible that a previous attempt to introduce unity builds to
our setup via cotire is interfering with the new, standardized unity
builds.  I am not too familiar with the details of that but I can try
to look into it.

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

[CMake] Unity builds vs. compile_commands.json (was: Re: [ANNOUNCE] CMake 3.16.0-rc1 is ready for testing)

[Paul Smith]

On Thu, 2019-10-10 at 14:57 -0400, Robert Maynard via CMake wrote:
> * The "UNITY_BUILD" target property was added to tell generators to
>   batch include source files for faster compilation times.

For some reason this didn't work with my actual cmake environment, but
I could enable it on a simple test environment.  I can look into that
later.

Here my concern is that you cannot use unity builds if you need
compile_commands.json (-DCMAKE_EXPORT_COMPILE_COMMANDS=ON); for example
if this is required by your IDE or other build tools.  When unity
builds are enabled the json file is not usable since it contains only
commands for the unity source files and doesn't describe the original
source files.

Is there an intent to address this before the 3.16 release?  

Or is this a known limitation, which may or may not be addressed in
some future version of CMake?

If the latter it should probably be added to the release notes and/or
documentation for unity builds.

Thanks!

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

[CMake] Unity builds (was: Re: [ANNOUNCE] CMake 3.16.0-rc1 is ready for testing)

[Paul Smith]

On Thu, 2019-10-10 at 14:57 -0400, Robert Maynard via CMake wrote:
> * The "UNITY_BUILD" target property was added to tell generators to
>   batch include source files for faster compilation times.

Are there any instructions on how to make this work?  I tried this:

  cmake -G 'Unix Makefiles' -DCMAKE_UNITY_BUILD=ON .

Then ran "make".  The output showed I had just as many output .o files
as input .cpp files and that make ran one compile command per .cpp
file.

Is there something else I need to do to enable unity builds in my cmake
files, than just give the above option?  The docs imply that the above
is all that's needed.

Cheers!

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] Why do executables link static libs that shared libs were built from?

[Paul Smith]

On Mon, 2019-06-17 at 11:43 +0200, Eric Noulard wrote:
> Yes you are right and I know that, but AFAIK when (with CMake) you
> TLL a shared lib to a static lib. You do not end up with any of the
> static lib symbol in the shared lib.

That can't be true, unless cmake is adding fancy linker options to the
command line (it doesn't :)).  The decision of what goes into the
library is up to how the linker works and what flags it's given.

However, note I said "it will have the _required_ contents" (emphasis
added).  As you noted, the .so will only pull in symbols from the .a
which are needed to link the .so.  That may not be all the symbols in
the .a, so in your test make sure you have that reference.

Alternatively you can configure the link of the shared library to use
"whole archive" mode which pulls in the entire contents of the .a
regardless of whether they are referenced.

> > I've added the static library to the creation of the shared
> > library:
> > 
> >   cc -shared -o bar.so bar.o libfoo.a
> > 
> > Now when bar.so is created it will have the required contents of
> > libfoo.a in it.
> 
> You mean that the part of libfoo.a which is actually used by some
> part of bar.o gets in bar.so or any [exported] symbol found in
> libfoo.a gets in bar.so with the same export rule?

The former (the part that is actually used).  However again, you can
force the linker to include everything, even unused symbols.

> If there is effectively no need to have static lib on the line
> because a shared lib depending on this static lib was already linked
> to it, then it ought to be suppressed and not rely on some linker
> policy to tidy up the whole set of shared and static libs.

I did come across a real problem that I don't know how to solve, caused
by this behavior.

I'm going to start a new thread about it since this one is long and
convoluted.

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] Why do executables link static libs that shared libs were built from?

[Paul Smith]

On Sun, 2019-06-16 at 21:42 +0200, Eric Noulard wrote:
> Le dim. 16 juin 2019 à 18:26, Paul Smith  a
> écrit :
> > But, that's not the only way to use shared libraries.  I'm trying
> > to collect a number of static libraries with different interfaces
> > into a single shared library that can be linked with executables. 
> 
> Correct me if I'm wrong but I guess that if your goal is to "collect"
> all those static libs *into* a shared lib then what you need is to
> make your STATIC libs,  OBJECT libs and then I think you'll get what
> you expect.

Yep, I'm familiar with OBJECT libs and if I could use them they would
give the correct behavior, you're right.  Unfortunately it's not the
case that OBJECT libraries are completely "drop-in" replaceable for
STATIC libraries, and they cannot be substituted in my environment.

See, for one example:
https://gitlab.kitware.com/cmake/cmake/issues/19388

I am not able to rework my system comprehensively enough to remove all
mutual references between all my current libraries.  And there are
other issues where OBJECT libraries aren't the equivalent of STATIC
libraries.

> Otherwise (at least in the way CMake currently works) any symbols
> defined in foo.a STATIC lib will *stay* in it. So in the end when you
> link an executable using bar.so SHARED lib only (which is using
> foo.a) then you won't have the symbol you need from foo unless foo.a
> is added to the link line ? Am I right?

No, that's not right.

The visibility of symbols depends on how your code is compiled and has
nothing to do with cmake and whether cmake links into a shared or
static library.

On POSIX systems (gcc and clang), all symbols are public by default
regardless of whether you are compiling them for a static or shared
library.

On Windows it's all more complicated, but in my situation I've added
the WINDOWS_EXPORT_ALL_SYMBOLS property to my libraries.

> But how can you do that without either:
>  
> 1) adding the static lib to any link line (including the one using bar)
> 2) *merging* foo.a *into* bar.so which should be what you achieve by
> making foo an OBJECT lib.

I'm not sure what you mean by "merging foo.a into bar.so": you can't
merge something into a shared library any more than you can merge
something into an executable.  By putting "foo" into the TLL of "bar",
I've added the static library to the creation of the shared library:

  cc -shared -o bar.so bar.o libfoo.a

Now when bar.so is created it will have the required contents of
libfoo.a in it.
 
> > If we can agree on that, then using the current rules of CMake
> > inheritance this implies that we can NEVER add a static library as
> > a PUBLIC TLL for a shared library.
> 
> Exactly my point. I understand what you say, but if ever CMake was
> doing that you simply couldn't switch (GLOBALLY) from SHARED to
> STATIC using 
> https://cmake.org/cmake/help/v3.14/variable/BUILD_SHARED_LIBS.html
> is a single SHARED lib was explicitely specified.

I wasn't familiar with that option, but I don't think it makes a
difference whether the libraries are made SHARED via this option or
whether they are made SHARED via direct specification: the behavior is
the same.

> My opinion is that CMake may handle TLL(SHARED STATIC) differently
> than TLL(SHARED SHARED) but forbidding the first would be a major
> headache when you want to go from STATIC to SHARED lib one step after
> another (I have a concrete example in mind in a legacy project).

I didn't say it should be forbidden!!

I said that as cmake is currently implemented it doesn't make sense to
do it, implying that cmake might want to change its behavior in this
area to be more useful.


However, after more investigation I see that I was wrong about how
linkers resolve symbols at least in POSIX systems (I'm not sure about
DLLs on Windows... I haven't gotten there yet).

For some reason I remembered that a linker would prefer symbols found
in static libraries over those found in shared libraries, but in fact
the linker will always choose the implementation of the symbol in the
first library it's defined in regardless of the type of library.

So, as long as the shared library appears first on the link line it
shouldn't matter that the static library also appears there.

I still think it's incorrect to add the static library to the link
line, but (at least for linkers with semantics as above) it probably
doesn't actually hurt anything.

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.

Re: [CMake] Why do executables link static libs that shared libs were built from?

[Paul Smith]

Let me just mention up-front that I spent about 2 weeks earlier this
year completely converting our circa-2011 cmake environment to ultra-
modern cmake: switching completely to TLL, interfaces, removing
virtually all if-statements and converting them into generator
expressions, etc.  So I'm very familiar with CMake's model for PRIVATE,
PUBLIC, and INTERFACE and how inheritance works.

And, I see the paradigm you're operating under where a shared library
provides a single "interface" that is public.

But, that's not the only way to use shared libraries.  I'm trying to
collect a number of static libraries with different interfaces into a
single shared library that can be linked with executables (in my case I
have 220 unit test programs which, when linked statically, not only
take a very long time and a lot of memory, but use about 45G of disk
space per build--I am collecting these into a shared library that can
be linked with our unit tests.  In my testing this reduces the size of
a sample unit test executable from 400M down to about 8M).

So: I need my shared library to export a combination of ALL the public
interfaces of the static libraries it was built from, but not,
obviously, export the static libraries themselves.


On Sat, 2019-06-15 at 23:10 -0700, Craig Scott wrote:
> The behaviour is correct according to what you are telling CMake to
> do. If you use PUBLC in a target_link_libraries() call, you are
> saying that anything that links to your shared library should also
> link to the static library.

That simply does not make sense, from the point of view of how a
program and a linker work (I understand it's how CMake works).

Let me work backwards, starting with a fact that hopefully we can all
agree on:

   It is NEVER appropriate to put a static library into the
   INTERFACE_LINK_LIBRARIES of a shared library.

I'd be interested to hear counter-arguments, but even if there are any
reasons for it my position is that in those very rare cases you should
be listing the static library in the TLL of the executable directly.

If we can agree on that, then using the current rules of CMake
inheritance this implies that we can NEVER add a static library as a
PUBLIC TLL for a shared library.

Which seems, to me, quite ridiculous because why shouldn't you want to
allow INTERFACE_COMPILE_DEFINITIONS, INTERFACE_COMPILE_OPTIONS, and
INTERFACE_COMPILE_DIRECTORIES of the static library to be inherited by
the shared library into its PUBLIC interface?  That seems like a quite
reasonable thing to want to do.

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

[CMake] Why do executables link static libs that shared libs were built from?

[Paul Smith]

I have a situation where I create a number of static libraries, then I
create a shared library from them, then I create an executable from the
shared library.

This seems straightforward, but I can't get it do work as I want.  The
behavior of STATIC -> SHARED for target property inheritance seems
incorrect to me.

I'm using CMake 3.14.5 on GNU/Linux for this test.

I need the compile properties of the static library (include
directories etc.) to be public for all users of the shared library as
well.  But obviously I don't want users of the shared library to also
link the static library!!  That defeats the whole purpose of the shared
library.

If I set up like this:

  $ touch foo.c bar.c
  $ echo 'int main() { return 0; }' > run.c

then write my CMakeFiles.txt like this:

  cmake_minimum_required(VERSION 3.13)
  project(Test C)

  add_library(foo STATIC foo.c)
  target_include_directories(foo PUBLIC /tmp)

  add_library(bar SHARED bar.c)
  target_link_libraries(bar PUBLIC foo)

  add_executable(run run.c)
  target_link_libraries(run PUBLIC bar)

Then, I DO get the -I/tmp forwarded up to run.c:

  cc -I/tmp -o CMakeFiles/run.dir/run.c.o -c run.c
 ^^

But libfoo.a is ALSO added to my link line, which is really wrong!

  cc CMakeFiles/run.dir/run.c.o  -o run -Wl,-rpath,. libbar.so libfoo.a
   

On the other hand if I change the link of foo to be PRIVATE instead of
PUBLIC:

  target_link_libraries(bar PRIVATE foo)

then the link doesn't include libfoo.a, which is good, but I also don't
have the -I/tmp when I compile run.c, which is wrong:

  cc -o CMakeFiles/run.dir/run.c.o -c run.c
  cc CMakeFiles/run.dir/run.c.o -o run -Wl,-rpath,. libbar.so

Does this seem wrong to anyone else?  Is there some trick to it?

Or do I have to resort to by-hand forwarding of build properties rather
than relying on a straightforward target_link_libraries() line?

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] How does IMPLICIT_DEPENDS work?

[Paul Smith]

On Sat, 2019-04-27 at 13:49 -0400, Paul Smith wrote:
> On Fri, 2019-04-26 at 17:26 -0400, Paul Smith wrote:
> > We're trying to implement precompiled headers (yes, I've seen all the
> > various github projects around this).  As part of this we need to make
> > sure the precompiled header is rebuilt whenever any of the headers that
> > it includes changes: this seems like exactly the job for
> > add_custom_command's IMPLICIT_DEPENDS.
> > 
> > But, it doesn't seem to be doing anything at all for me so I wonder
> > what I'm doing wrong.
> 
> OK, I figured out the issue.  The problem is a combination of the way I
> was testing and a sort of bizarre "feature" of the CMake Makefile
> generator

I re-confirmed the documented restriction that IMPLICIT_DEPENDS is not
available for non-Makefile generators (e.g., Ninja).

Without this facility it seems impossible to support precompiled
headers in CMake, so I've had to disable PCH for non-Makefile (and non-
MSVC of course) generators.

Is there any chance of getting IMPLICIT_DEPENDS support for Ninja?  Is
the reason that it's not supported because Ninja does its own
dependency management or something like that?  Does anyone know how
it's done?  Is it done by using the compiler flags like -MMD/-MP etc.
or does it have its own built-in facility?

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] How does IMPLICIT_DEPENDS work?

[Paul Smith]

On Fri, 2019-04-26 at 17:26 -0400, Paul Smith wrote:
> We're trying to implement precompiled headers (yes, I've seen all the
> various github projects around this).  As part of this we need to make
> sure the precompiled header is rebuilt whenever any of the headers that
> it includes changes: this seems like exactly the job for
> add_custom_command's IMPLICIT_DEPENDS.
> 
> But, it doesn't seem to be doing anything at all for me so I wonder
> what I'm doing wrong.

OK, I figured out the issue.  The problem is a combination of the way I
was testing and a sort of bizarre "feature" of the CMake Makefile
generator:

The Makefile generator only generates prerequisite information when a
CMake target is completely built.  It doesn't generate the information
when an individual object file is built.

I was testing (to allow faster turnaround) by simply running:

  cmake ...
  make foo.cpp.o
  touch header.h
  make foo.cpp.o

and the PCH file was not being rebuilt even though it included
header.h.  After MUCH tearing of hair and groping around in the
generated makefiles, I realized that unless I built the full target and
not just the individual object file, no prerequisite information was
created.  I had to run:

  cmake ...
  make footarget
  touch header.h
  make foo.cpp.o

The first make would build foo.cpp.o and also generate all the
prerequisite information as a side-effect of creating footarget.  Then
the second make would correctly update the PCH file in addition to
rebuilding the object file.

Note this is not related to PCH at all: you can reproduce this with the
simplest of CMake configurations.

That is definitely a subtlety of the makefile generator that was
unexpected: maybe it will help someone else trying to do similar
testing.

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

[CMake] How does IMPLICIT_DEPENDS work?

[Paul Smith]

We're trying to implement precompiled headers (yes, I've seen all the
various github projects around this).  As part of this we need to make
sure the precompiled header is rebuilt whenever any of the headers that
it includes changes: this seems like exactly the job for
add_custom_command's IMPLICIT_DEPENDS.

But, it doesn't seem to be doing anything at all for me so I wonder
what I'm doing wrong.

I'm using CMake 3.13.4 on GNU/Linux with GCC C++ and Makefile
generators (we also will have support for MSVC but I'm not worried
about that here).

I have a function to deal with PCH generation:

  function(add_precompiled_header _target _header)
...
  # This is the actual command that does the precompiling
  add_custom_command(
  OUTPUT "${_pch_file}"
  COMMAND "${CMAKE_COMMAND}" -E make_directory "${_pch_dir}"
  COMMAND "${CMAKE_CXX_COMPILER}" "${_flags}" -x c++-header -o
"${_pch_file}" "${_header}"
  COMMAND_EXPAND_LISTS
  IMPLICIT_DEPENDS CXX "${_header}"
  COMMENT "Precompiling ${_header} for ${_target} (C++)")
...
  get_property(_sources TARGET ${_target} PROPERTY SOURCES)
  foreach(_source ${_sources})
...
  set_property(SOURCE ${_source} APPEND PROPERTY
  OBJECT_DEPENDS "${_pch_file}")
...
  endforeach()

Obviously there're a lot of other things here I'm leaving out, but
basically there's a custom command that compiles the header into a PCH
and lists the header as an IMPLICIT_DEPENDS, and adds that PCH as an
OBJECT_DEPENDS to the source files.

When I change the PCH file, the source files are rebuilt so that works.

If I change the header the PCH file is rebuilt so that works too.

But if I change a header file that the PCH includes, the PCH is NOT
rebuilt.  Not only that but if I use "make -d" I can see that the PCH
target never even considers any of the included files when determining
out-of-date-ness of the PCH file.

It seems like IMPLICIT_DEPENDS is behaving identically to DEPENDS here:
only listing the header as a dependency but not trying to determine
what it, itself, depends on.

What am I doing wrong?  Is there some subtlety to IMPLICIT_DEPENDS that
I'm missing?

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] Fake dependencies of executables to static libs

[Paul Smith]

On Thu, 2019-04-04 at 06:56 +0100, Stephan Menzel wrote:
> add_library(mylib STATIC mysources)
> add_excecutable(mytest mytest.cpp)
> target_link_libraries(mytest mylib)
> 
> Now although I don't understand the exact reasons behind that, over
> the years came to accept that depedencies between the lib and the
> resulting artifcats are not working. Like, when I change a source
> file to mylib, the lib will get rebuilt but the resulting test tool
> won't be relinked.

This is definitely not true, as stated.  I feel like I must be missing
something about your stated environment because this is really basic,
fundamental CMake behavior, which has always worked.

If in your environment you are not seeing executables rebuilt when
libraries they depend on are updated, then there is something more
complex about it than the straightforward case you provide above.

Rather than try to find a workaround it would be better to find the
root cause.  If you can provide a sample setup that behaves as you
describe perhaps we could explain what's happening.

Also please let us know which version of CMake you're using.
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] Visual Studio generator running custom_command twice

[Paul Smith]

On Thu, 2019-03-14 at 13:30 -0400, frodak17 wrote:
> On Thu, Mar 14, 2019 at 12:53 PM frodak17  wrote:
> > On Thu, Mar 14, 2019 at 1:13 AM Paul Smith 
> > wrote:
> > > I have a situation where I've created a custom command to
> > > generate .cpp
> > > 
> > > files to be compiled (in my case running bison/flex).
> > > 
> > > 
> > > 
> > > I'm using CMake 3.13.4
> > > 
> > > 
> > > 
> > >   set(MyParserOutput
> > > 
> > >   ${OUT_DIR}/MyParser.tab.cpp
> > > 
> > >   ${OUT_DIR}/MyParser.tab.hpp)
> > > 
> > > 
> > > 
> > >   add_custom_target(MyGenParser DEPENDS ${MyParserOutput})
> > > 
> > > 
> > > 
> > > Then I have two different libraries, both depending on this:
> > > 
> > > 
> > > 
> > >   add_library(OneLib STATIC ${MyParserOutput} ...)
> > > 
> > > 
> > >   add_dependencies(OneLib MyGenparser)
> > > 
> > > 
> > > 
> > > 
> > > 
> > >   add_library(TwoLib STATIC ${MyParserOutput} ...)
> > > 
> > > 
> > >   add_dependencies(TwoLib MyGenparser)
> > > 
> > > 
> > From add_custom_command() 
> > Do not list the output in more than one independent target that
> > may build in parallel or the two instances of the rule may conflict
> > (instead use the add_custom_target() command to drive the
> > command and make the other targets depend on that one)

Yeah, I did see that in the manual and I do that, as above.  It wan't
at all clear to me that in addition to those requirements, I ALSO could
NOT list the output of the add_custom_command() in any of my other
targets.

That's unfortunate :(.

> In that case you need to keep ${MyParserOutput} and set the GENERATED
> properties for the files.
> 
> Also the building the custom target needs to be done in a separate
> directory as the add_custom_commands() need to be in a different
> CMakeLists.txt file from the libraries.  Otherwise the rules get
> pulled into the libraries and cause the commands to be run multiple
> times.

Ouch.  That's painful as it could mean moving my code around.

However in this case it ended up not being too horrible because my
parser input files happened to be in a subdirectory already, so I
created a new CMakeLists.txt file there that only ran the generators,
then used set(... PARENT_SCOPE) to publish the variables to the parent
directory.

I did then have to add a GENERATED property to those files in the
parent directory, as you noted, so overall it's a bit leaky in terms of
abstractions, but it seems to work... now when I run on Windows I see
that the generators are run only one time.

Thanks for the help!!
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

[CMake] Visual Studio generator running custom_command twice

[Paul Smith]

I have a situation where I've created a custom command to generate .cpp
files to be compiled (in my case running bison/flex).

I'm using CMake 3.13.4

However, I have to compile this code in two different ways for two
different targets.  I am seeing the Visual Studio generator re-running
bison/flex once for each of these targets, which is (a) not necessary
and (b) causes my builds to fail since it often happens that the second
run can't replace the output files (due to Windows' annoying habit of
locking files that are open).

I have a custom command like this:

 add_custom_command(OUTPUT
  ${OUT_DIR}/MyParser.tab.cpp
  ${OUT_DIR}/MyParser.tab.hpp
  COMMAND ${CMAKE_COMMAND} -E make_directory ${OUT_DIR}
  COMMAND ${BISON} -d -o ${OUT_DIR}/MyParser.tab.cpp MyParser.y
  DEPENDS MyParser.y
  COMMENT "Building MyParser parser")

  set(MyParserOutput
  ${OUT_DIR}/MyParser.tab.cpp
  ${OUT_DIR}/MyParser.tab.hpp)

  add_custom_target(MyGenParser DEPENDS ${MyParserOutput})

Then I have two different libraries, both depending on this:

  add_library(OneLib STATIC ${MyParserOutput} ...)

  target_compile_definitions(OneLib PRIVATE -DONELIB)

  target_include_directories(OneLib PRIVATE ${OUT_DIR})

  add_dependencies(OneLib MyGenparser)


  add_library(TwoLib STATIC ${MyParserOutput} ...)

  target_compile_definitions(TwoLib PRIVATE -DTWOLIB)

  target_include_directories(TwoLib PRIVATE ${OUT_DIR})

  add_dependencies(TwoLib MyGenparser)


On Linux and MacOS, this works fine.  However on Windows with Visual
Studio I see the custom target being run twice, once for each library:

  18:27:10 21>PrepareForBuild:
  18:27:10  Creating directory "OneLib.dir\RelWithDebInfo\".
  18:27:10  Creating directory "OneLib.dir\RelWithDebInfo\OneLib.tlog\".
  18:27:10InitializeBuildStatus:
  18:27:10  Creating 
"OneLib.dir\RelWithDebInfo\OneLib.tlog\unsuccessfulbuild" because 
"AlwaysCreate" was specified.
  18:27:10ComputeCustomBuildOutput:
  18:27:10  Creating directory "D:\builds\src\".
  18:27:10CustomBuild:
  18:27:10  Building MyParser parser

Then again later:

  18:27:20 69>PrepareForBuild:
  18:27:20  Creating directory "TwoLib.dir\RelWithDebInfo\".
  18:27:20  Creating directory "TwoLib.dir\RelWithDebInfo\TwoLib.tlog\".
  18:27:20InitializeBuildStatus:
  18:27:20  Creating 
"TwoLib.dir\RelWithDebInfo\TwoLib.tlog\unsuccessfulbuild" because 
"AlwaysCreate" was specified.
  18:27:20CustomBuild:
  18:27:20  Building MyParser parser

See how this second one is re-building the parser; then this fails
because the output file is locked by Windows (in use by the compiler):

  18:27:21 69>CustomBuild:
  18:27:21  bison.exe: could not create D:/builds/src/MyParser.tab.cpp
  18:27:25 69>C:\Program Files (x86)\Microsoft Visual 
Studio\2017\Professional\Common7\IDE\VC\VCTargets\Microsoft.CppCommon.targets(209,5):
 error MSB6006: "cmd.exe" exited with code 1. [D:\builds\TwoLib.vcxproj]

How can I get CMake to only run the bison command one time, then use
the output for two different libraries?

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] Getting the path to object files?

[Paul Smith]

On Wed, 2019-02-27 at 08:39 -0500, Robert Maynard wrote:
> CMake only provides an official way to get the location of the object
> files for OBJECT targets ( $ ). For other
> target types the location is an implementation detail.

Yes, but sometimes (as in my case) I need to know it :).  I need to
examine the object files as part of my link processing.

Exactly _because_ it's an implementation detail, it would be nice if
there were some way to retrieve it from CMake.  I can file an
enhancement request if that seems appropriate.

I could use an OBJECT target if it weren't for the Xcode restriction
that a STATIC or SHARED library must have at least one source file and
can't consist solely of an OBJECT library.

I'm hopeful we can throw away our MacOS builds entirely but until that
happens...


Thanks for the reply Robert!

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

[CMake] Getting the path to object files?

[Paul Smith]

Hi all.  I'm using CMake 3.13.4 across Linux, MacOS, and Windows, with
various generators.

I need to write a script (this only runs on Linux actually) that will
do some processing on all the object files in a shared library and
generate a linker version file.  I'm trying to write a custom command
using PRE_LINK that will invoke that script and pass along enough
information to find all those object files so it can generate the
version file, and I can't come up with it.

For example, using a Makefile generator for a file "libsrc.cpp" built
for a library "solib" in a directory "LibDir" on Linux my object file
paths look like:

  LibDir/CMakeFiles/solib.dir/libsrc.cpp.o

I can use something like this:

  get_target_property(srcs solib SOURCES)

  add_custom_command(TARGET solib PRE_LINK
  COMMAND foo ${srcs}
  VERBATIM)

(for some reason if I try to use a generator expression like
$ etc. it's always passed as a single quoted
argument and I can't figure out how break it up, but if I use
get_target_property() then it works correctly).

However this only gives me the source file names, not the object file
names, and no directory information to search.  My problem is I'm
actually compiling these same source files multiple times in different
ways for different libraries, so I can't just search for "libsrc.cpp.o"
I need to get this particular .o.

So then I added $ which looked promising,
but it only gives me the path to the source directory; i.e. above it
gives me LibDir.

I tried lots of different likely-looking properties, but I can't find
any property which will tell me the path I'm looking for.

Can I get CMake to tell me the path where the object files being
created will be put for a given target?  Or do I just need to hard-code 
it based on my observations of how cmake generators actually create the
output?

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] Static libraries depending on libraries: only on headers/options/defines

[Paul Smith]

I wrote this function.  At first attempt it seems to do what I want but
I've definitely not completed my work so I may well still find issues
with it.

Basically it does everything that target_link_libraries() does (at
least, it tries to as best as I understand it other than a bunch of
properties I don't know what they are and don't use) with one caveat:
it adds libraries to INTERFACE_* but not LINK_LIBRARIES:

function(static_link_libraries tgt mode)
foreach(lib ${ARGN})
# Import all the source-level properties as normal
foreach(t COMPILE_DEFINITIONS COMPILE_FEATURES COMPILE_OPTIONS
  INCLUDE_DIRECTORIES SOURCES SYSTEM_INCLUDE_DIRECTORIES)
if(${mode} STREQUAL "PRIVATE" OR ${mode} STREQUAL "PUBLIC")
set_property(TARGET ${tgt} APPEND PROPERTY
${t} $)
endif()
if(${mode} STREQUAL "PUBLIC" OR ${mode} STREQUAL "INTERFACE")
set_property(TARGET ${tgt} APPEND PROPERTY
INTERFACE_${t} $)
endif()
endforeach()
# Import all the library-level properties as INTERFACE only
foreach(t LINK_DEPENDS LINK_DIRECTORIES LINK_OPTIONS)
set_property(TARGET ${tgt} APPEND PROPERTY
INTERFACE_${t} $)
endforeach()
# Import the library itself as INTERFACE only
set_property(TARGET ${tgt} APPEND PROPERTY
INTERFACE_LINK_LIBRARIES ${lib})
endforeach()
endfunction()



On Sat, 2019-02-16 at 23:03 +0100, Andreas Naumann wrote:
> Hi Paul,
> 
> I understand the relationship between libraries as strict, such that you 
> always build all dependent libraries before.
> In your use case I thought about splitting the libraries in the actual 
> target and the interface one.
> For example, you could create an interface library foo_interface
> add_library(foo_interface INTERFACE )
> set the properties and then link foo and bar to this interface library 
> using target_link_libraries.
> 
> But be aware, that now every executable, which links against bar must 
> manually link against foo. If your project is large, this seems not 
> really desirable. But I think you could also split the library bar in 
> two bar_withoutFoo and bar. The library bar_withoutFoo would link 
> against foo_interface and compile the sources, whereas bar is an 
> interface library which depends on bar_withoutFoo and foo.
> The developer could than build bar completely independent from foo and 
> you could transport the transitive dependencies to the executable.
> 
> I don't know if this doubled structure using pure interfaces libraries 
> and the actual libraries is maintainable.
> 
> Hope that helps a bit,
> Andreas
> 
> Am 16.02.19 um 20:20 schrieb Paul Smith:
> > Hi all;
> > 
> > I'm working on modernizing our large complex CMake environment.  It
> > builds a number of different binaries from an even larger number of
> > static libraries, and these libraries depend on each other as well, in
> > that they need to include headers and, sometimes, -D options etc.
> > 
> > I've used straightforward target_link_libraries() to declare the
> > relationship between these libraries; for example:
> > 
> >add_library(foo STATIC ...)
> >target_include_directories(foo PUBLIC ...)
> >target_compile_definitions(foo PUBLIC ...)
> >target_compile_options(foo PUBLIC ...)
> > 
> >add_library(bar STATIC ...)
> >target_link_libraries(bar PUBLIC foo)
> > 
> >add_executable(one ...)
> >target_link_libraries(one PRIVATE bar)
> > 
> > This works, in that everything builds properly but it has a side-effect
> > we want to avoid.  Because the source tree is large many developers
> > have a habit of testing compilation of subsets of the code using
> > something like:
> > 
> >make -jX bar
> > 
> > and expect it to just build the static library bar.  Because it's a
> > static library you don't need to actually build "foo" until link time.
> > But we do need all the include directories, compile definitions, and
> > compile options to be inherited from "foo" into "bar".
> > 
> > However with the above formulation, building "bar" also forces the
> > compilation of "foo", which we don't need or want.
> > 
> > I've played around with the different values of PUBLIC, PRIVATE, and
> > INTERFACE but there doesn't seem to be a straightforward way to say,
> > "take the interface values for includes, definitions, and options, but
> > don't depend on the generated target".
> > 
> > I can write a function to do th

[CMake] Static libraries depending on libraries: only on headers/options/defines

[Paul Smith]

Hi all;

I'm working on modernizing our large complex CMake environment.  It
builds a number of different binaries from an even larger number of
static libraries, and these libraries depend on each other as well, in
that they need to include headers and, sometimes, -D options etc.

I've used straightforward target_link_libraries() to declare the
relationship between these libraries; for example:

  add_library(foo STATIC ...)
  target_include_directories(foo PUBLIC ...)
  target_compile_definitions(foo PUBLIC ...)
  target_compile_options(foo PUBLIC ...)

  add_library(bar STATIC ...)
  target_link_libraries(bar PUBLIC foo)

  add_executable(one ...)
  target_link_libraries(one PRIVATE bar)

This works, in that everything builds properly but it has a side-effect 
we want to avoid.  Because the source tree is large many developers
have a habit of testing compilation of subsets of the code using
something like:

  make -jX bar

and expect it to just build the static library bar.  Because it's a
static library you don't need to actually build "foo" until link time. 
But we do need all the include directories, compile definitions, and
compile options to be inherited from "foo" into "bar".

However with the above formulation, building "bar" also forces the
compilation of "foo", which we don't need or want.

I've played around with the different values of PUBLIC, PRIVATE, and
INTERFACE but there doesn't seem to be a straightforward way to say,
"take the interface values for includes, definitions, and options, but
don't depend on the generated target".

I can write a function to do this myself but this seems like the most
common way someone would want to treat static libraries referencing
other static libraries, so I wondered if I was missing something that would 
allow this in a simpler way.

Thanks!

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] OBJECT libraries getting fully support?

[Paul Smith]

On Tue, 2019-02-12 at 16:19 -0800, Michael Ellery wrote:
> https://cmake.org/cmake/help/latest/release/3.12.html
>  says that target_link_libraries got OBJECT in 3.12 - is that what
> you had in mind?

Aha!  Of course, we're using the most recent 3.11 version.  Isn't it
always the way it goes?

OK I'll test with a newer version of CMake and see if I can get things
to work.

It would be great if anyone knows of a way to force a library to be
listed "last" (or near the end anyway) of an executable link line
regardless of dependency information described by
target_link_libraries() (when using modern CMake methods).

If I could do that I could avoid needing the OBJECT library in the
first place and just use a STATIC library.

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] OBJECT libraries getting fully support?

[Paul Smith]

Don't want to be a noodge but wondering if anyone has any thoughts
about this question or ideas on how to solve my problem?


On Sat, 2019-02-09 at 12:29 -0500, Paul Smith wrote:
> Hi all;
> 
> I saw an email to the list from Chuck Atkins in the summer of 2017
> suggesting that OBJECT libraries were being enhanced and could become
> fully-functional libraries hopefully sometime that year.  I'm wondering
> if that ever actally happened and if so what release of cmake it was
> in, and if not is there still a plan for this sometime?
> 
> I'm trying to convert a large and complex cmake environment originally
> started in 2007 or so, which uses all old-school cmake facilities, to
> use modern cmake methods.
> 
> I have a situation where we have a library containing basic methods
> which can be implemented multiple ways and different executables use
> different implementations.  However these methods are used by all sorts
> of static libraries as well.
> 
> Since we don't know until executable link time which library to use,
> the static libraries cannot depend on the base library: it has to be
> listed only in the executable's target_link_libraries.  But of course
> because the static libraries use them as well we need the base library
> to be listed last (or near last) in the link line else we get undefined
> symbols.  Adding the base library to the executable TLL doesn't allow
> us to do that.
> 
> So I was thinking of making this base library an OBJECT library so it
> would always be fully linked but it seems that our version of cmake
> doesn't allow an OBJECT library to be used as a normal library and I'd
> be reduced to adding lots of generator expressions for it everywhere
> which is a huge PITA.
> 
> Any ideas on how best to address this situation, if OBJECT libraries
> are not supported yet?

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

[CMake] OBJECT libraries getting fully support?

[Paul Smith]

Hi all;

I saw an email to the list from Chuck Atkins in the summer of 2017
suggesting that OBJECT libraries were being enhanced and could become
fully-functional libraries hopefully sometime that year.  I'm wondering
if that ever actally happened and if so what release of cmake it was
in, and if not is there still a plan for this sometime?

I'm trying to convert a large and complex cmake environment originally
started in 2007 or so, which uses all old-school cmake facilities, to
use modern cmake methods.

I have a situation where we have a library containing basic methods
which can be implemented multiple ways and different executables use
different implementations.  However these methods are used by all sorts
of static libraries as well.

Since we don't know until executable link time which library to use,
the static libraries cannot depend on the base library: it has to be
listed only in the executable's target_link_libraries.  But of course
because the static libraries use them as well we need the base library
to be listed last (or near last) in the link line else we get undefined
symbols.  Adding the base library to the executable TLL doesn't allow
us to do that.

So I was thinking of making this base library an OBJECT library so it
would always be fully linked but it seems that our version of cmake
doesn't allow an OBJECT library to be used as a normal library and I'd
be reduced to adding lots of generator expressions for it everywhere
which is a huge PITA.

Any ideas on how best to address this situation, if OBJECT libraries
are not supported yet?

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] CMake 3.11.3: set properties on the command line?

[Paul Smith]

On Tue, 2018-12-18 at 08:22 +1100, Craig Scott wrote:
> If you are setting your own sysroot, are you using a toolchain file?
> You could put your set_property() command in your toolchain file if
> you're using one.
> Those techniques aside, it's interesting that you need to add this
> manual workaround at all. I suspect this code might be why it is
> being turned off for you, but without more detail about your build
> setup, it's hard to say. If you use a toolchain file and set
> CMAKE_SYSTEM_NAME to anything (even the same as the
> CMAKE_HOST_SYSTEM_NAME), CMAKE_CROSSCOMPILING will be TRUE, which I
> suspect would prevent the problem you're seeing.

I was not using a toolchain file, but switching to use one (that set
CMAKE_SYSTEM_NAME) solved the problem.

Thanks!
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

[CMake] CMake 3.11.3: set properties on the command line?

[Paul Smith]

Hi all.

I'm using cmake with a cross-compiler environment, but building third
party packages that are configured with CMake.  So when I invoke cmake
for those packages I add this options to the command line:

  -DCMAKE_FIND_ROOT_PATH=/my/sysroot

However, this is not working because it's finding 32bit libraries.  For
example if the package's CMakeLists.txt file contains this:

  find_package(ZLIB REQUIRED)

then my link line ends up containing:

  /my/sysroot/usr/lib/libz.so

which is the 32bit version and the link fails.  The 64bit version DOES
exist exactly as it should:

  $ ls -1 /my/sysroot/usr/lib*/libz.so*
  /my/sysroot/tools/usr/lib/libz.so
  /my/sysroot/tools/usr/lib64/libz.so

and the link works if I do it by hand with the right path.  I don't
know why it's not automatically looking for lib64; I checked and CMake
knows I want a 64bit build.  For example I see this after running:

  CMakeFiles/3.11.3/CMakeCXXCompiler.cmake:set(CMAKE_CXX_SIZEOF_DATA_PTR "8")

Actually I wish cmake would just add "-lz" to the command line and let
the linker figure it all out rather than trying to second-guess things.
Then it would "just work".

In any event, if I edit the CMakeLists.txt in the package to set the
global property FIND_LIBRARY_USE_LIB64_PATHS to ON, then it all works
fine:

  set_property(GLOBAL PROPERTY FIND_LIBRARY_USE_LIB64_PATHS ON)

But I can't see any way to set that property from the command line,
without editing the package's CMakeLists.txt file which I obviously
don't want to do.

Help for either (a) figuring out why cmake incorrectly chooses 32bit
libraries or (b) setting the property without editing third-party
CMakeLists.txt files would be much appreciated!!

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] Can I build targets during all but NOT during install?

[Paul Smith]

On Mon, 2018-01-01 at 18:12 -0500, Paul Smith wrote:
> What I hoped is for the default build with no targets specified to
> build everything ("all"), but if I invoke the build with the
> "install" target it builds only the things that are to be installed,
> not my test programs.
> 
> Unfortunately it doesn't seem like this is possible; at least when I
> examine the Makefiles generated by the CMake Unix Makefiles
> generator, the install target depends on the preinstall target which
> depends on all.  Is this true in general or is there something in my
> CMake setup that causes it?

FYI I'm using CMake 3.11.3 on GNU/Linux, MacOS, and Windows with Visual
Studio.

Thanks to Oleksii Vilchanskyi  for
pointing me to CMAKE_SKIP_INSTALL_ALL_DEPENDENCY.

This appears (not tested completely yet) to do half of what I'd like,
by keeping the "install" target from depending on "all".


The other half is that I want to have the "all" target depend on
"install", instead: all should build all the installation targets AND
also build all the extra testing stuff that is not needed during
install.

I can't seem to figure out how to do that; add_dependencies()
explicitly says that I can't use it with "install" and I don't see any
other way to add dependencies to a target.

Is this possible?  Or do I need to go around to all my "all"
dependencies and explicitly add them to "install" as well?


Then the next step after that is I'd like my "install" target to have
dependencies which are built during installation but don't actually
copy any files anywhere: they are just built and left as-is when I run
the "install" rule (e.g., "make install" or whatever).

I can't come up with a way to modify the dependencies of the "install"
target without using the install() rule.

The manual says that the DESTINATION option in install() is optional,
but if I leave it out I get errors.

Is that possible?
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] CMake 3.11: Gives wrong paths to ar/strip/etc. when overridden

[Paul Smith]

On Thu, 2018-06-14 at 11:41 +0200, Deniz Bahadir wrote:
> > But all the other bintools variable overrides do the wrong thing:
> > 
> >* -DCMAKE_AR=my-ar   --> CMAKE_AR=/tmp/obj/my-ar
> >* -DCMAKE_LINKER=my-ld   --> CMAKE_LINKER=/tmp/obj/my-ld
> >* -DCMAKE_RANLIB=my-ranlib   --> CMAKE_RANLIB=/tmp/obj/my-ranlib
> >* -DCMAKE_STRIP=my-strip --> CMAKE_STRIP=/tmp/obj/my-strip
> >* -DCMAKE_OBJCOPY=my-objcopy --> CMAKE_OBJCOPY=/tmp/obj/objcopy
> > 
> 
> This is what I would have expected.
> If you just give the executable's name as value to the variable an 
> implicit "./" is seen by CMake which when translated into an
> absolute path results in "./" being replaced by the current working-
> directory of CMake (which seems to be "/tmp/obj/").

Thanks for the note!

IMO, that's just manifestly wrong behavior.

Either CMake should leave my values alone and use them exactly as I set
them, or if it wants to handle these values specially because it knows
they are binaries and wants to enforce a fully-qualified path (which is
unnecessary IMO but whatever), then at least it should do that
correctly and perform a PATH lookup for them.

Forcing them to be "./binary" when that's not what I said is completely
unexplainable.  In what universe would looking for CMAKE_AR, etc. in
the local directory ever be the right thing to do?

> > Can anyone explain this, and hopefully help me find a way to fix
> > it?  Am I just doing variables wrong here?  How should I do it?
> 
> I recommend to us the fully qualified path to your alternative 
> executables as values for the variables. That should do the trick.

So you're saying that rather than relying on the operating system's
path lookup capabilities, which exist for exactly this reason, I have
to recreate that operation myself by hand (or in some sort of wrapper
script) for all my binaries before I can invoke cmake?

> PS: You are right that the behavior seems to be inconsistent for 
> different variables and should be similar for all variables. So I 
> recommend you file a bug-report in CMake's issue-tracker.

That does seem like the next step.  Filed:

https://gitlab.kitware.com/cmake/cmake/issues/18087

Thanks!
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

[CMake] CMake 3.11: Gives wrong paths to ar/strip/etc. when overridden

[Paul Smith]

I've discovered that CMake is not correctly locating ar/strip/etc. if I
override the names of these tools on the command line.  I've tried this
with 3.5.2 as well and I get the same incorrect behavior.

Here's an example (this is on a GNU/Linux system):

$ type -a my-ar
/work/bin/my-ar

$ my-ar --version | head -n1
GNU ar (GNU Binutils) 2.30

$ pwd
/tmp/obj

$ cat ../CMakeLists.txt
PROJECT(foobar)
CMAKE_MINIMUM_REQUIRED(VERSION 3.0)

$ cmake --version | head -n1
cmake version 3.11.3

$ cmake -DCMAKE_AR=my-ar ..
  ...

$ grep CMAKE_AR CMakeCache.txt
CMAKE_AR:FILEPATH=/tmp/obj/my-ar
//ADVANCED property for variable: CMAKE_AR
CMAKE_AR-ADVANCED:INTERNAL=1


Note how, instead of either using just "my-ar" or else the fully-
qualified path "/work/bin/my-ar", CMake uses the bogus and completely
non-existent path "/tmp/obj/my-ar".  This causes my builds to fail,
obviously.

I tried enabling debug-output, trace, and trace-expand but there are no
clues there as to why CMake prefixes these paths with the local object
directory.

I should note that resetting the C and C++ compilers works:

 * -DCMAKE_C_COMPILER=my-gcc   --> CMAKE_C_COMPILER=/work/bin/my-gcc
 * -DCMAKE_CXX_COMPILER=my-g++ --> CMAKE_CXX_COMPILER=/work/bin/my-g++

But all the other bintools variable overrides do the wrong thing:

 * -DCMAKE_AR=my-ar   --> CMAKE_AR=/tmp/obj/my-ar
 * -DCMAKE_LINKER=my-ld   --> CMAKE_LINKER=/tmp/obj/my-ld
 * -DCMAKE_RANLIB=my-ranlib   --> CMAKE_RANLIB=/tmp/obj/my-ranlib
 * -DCMAKE_STRIP=my-strip --> CMAKE_STRIP=/tmp/obj/my-strip
 * -DCMAKE_OBJCOPY=my-objcopy --> CMAKE_OBJCOPY=/tmp/obj/objcopy

Can anyone explain this, and hopefully help me find a way to fix it? 
Am I just doing variables wrong here?  How should I do it?

Thanks!
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] Building cmake: why is openssl linked?

[Paul Smith]

On Sun, 2018-01-14 at 01:08 +0100, Jean-Michaël Celerier wrote:
> https://cmake.org/cmake/help/latest/module/ExternalProject.html
> 
> since CMake can download stuff, it needs to support https, hence SSL,
> hence OpenSSL

OK, thanks.

Does anyone know if there is way to convince CMake to use a decent SSL
library, like libressl or something, rather than the really horribly
managed openssl?

In the meantime I'll omit support for this in my builds of cmake, since
I don't actually use that feature.

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

[CMake] Building cmake: why is openssl linked?

[Paul Smith]

Hi all.

I build CMake myself.  I've noticed that on GNU/Linux by default cmake
will be linked with openssl and require these shared libraries to be
available at runtime.

Why does cmake link with these libraries?  I can't think of a reason it
might need them.  What do I lose in functionality if I force
CMAKE_USE_OPENSSL to OFF during the build?
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

[CMake] Can I build targets during all but NOT during install?

[Paul Smith]

I have (what I thought was) a common environment where my build creates
both programs to be installed and also test programs etc. that aren't
installed.

What I hoped is for the default build with no targets specified to
build everything ("all"), but if I invoke the build with the "install"
target it builds only the things that are to be installed, not the test
programs.

Unfortunately it doesn't seem like this is possible; at least when I
examine the Makefiles generated by the CMake Unix Makefiles generator,
the install target depends on the preinstall target which depends on
all.  Is this true in general or is there something in my CMake setup
that causes it?

I find this very limiting: it seems clear to me that a default "all"
build might create all sort of other things that aren't installed via
the "install" target... I should be able to build "install" to only
build those things not "all" the things.

Any ideas for this?
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

[CMake] find_package() locating 32bit libs incorrectly

[Paul Smith]

Hi all.

I'm trying to build LLVM/Clang locally on my Linux system, but I'm using
a separate set of system headers and libraries.  These appear in a
separate sysroot directory, like this:

  /sysroot/tools/usr/lib64/...
  /sysroot/tools/usr/lib/...
  /sysroot/tools/usr/include/...

This is basically an extracted set of Red Hat 6 system libraries, so the
content in usr/lib are 32bit libraries and the content in usr/lib64 are
64bit libraries.

I'm building LLVM/Clang 4.0 and in the Clang CMakeLists.txt file we have
simply:

  find_package(LibXml2 2.5.3 QUIET)

There are libxml2.so files in both the 64bit and 32bit lib directories
above as well as the usr/include directory.

I run cmake with -DCMAKE_PREFIX_PATH=/sysroot/tools/usr, and CMake finds
things in my sysroot.  However, it uses the *32bit* libraries instead of
the 64bit ones; CMakeCache.txt says:

  //Path to a file.
  LIBXML2_INCLUDE_DIR:PATH=/sysroot/tools/usr/include/libxml2

  //Path to a library.
  LIBXML2_LIBRARIES:FILEPATH=/sysroot/tools/usr/lib/libxml2.so

The latter should be finding usr/lib64/libxml2.so instead.  Because of
this incorrect behavior the link of Clang fails (because it's a 64bit
executable trying to link a 32bit library).

I'm using a slightly older CMake (3.5.2) but I'd assume find_package()
understands the standard directory structure used by Red Hat.

Is there a way to convince CMake find_package() to look in the right
directory?
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] CMake 3.7.2 and parallel builds

[Paul Smith]

On Fri, 2017-01-27 at 15:45 -0400, Dave Flogeras wrote:
> I've recently upgraded to CMake 3.7.2 (and gnu make-4.2.1). Now, when
> I execute 'make -j5 NightlyBuild', I get the following new (to me)
> warning:
> 
> "gmake[4]: warning: jobserver unavailable: using -j1.  Add '+' to parent make 
> rule."
> 
> If I downgrade make back to the previous version, 4.1-r1 (the -r1 is
> Gentoo), the warning goes away again.
> 
> If I use CMake-3.6.3 (my previous version) with make-4.2.1, the
> warning is still there.
> 
> Is this a known issue?  Is it something I am doing wrong in my
> scripts?

My suspicion is that somehow the recursion is invoking an older version
of make.  In GNU make 4.2 the jobserver interface was stabilized and
published, so that other build tools could take advantage of it (if
desired); for example if your linker is multithreaded it could
participate in the jobserver feature, obtaining jobserver tokens for its
threads so it didn't overwhelm the system during linking.

As part of this the command-line interface between a parent make and its
sub-makes was changed.  This means that if a parent make tries to invoke
a sub-make and they have different versions there may be an
incompatibility.

Normally this is very difficult to do because GNU make sets the MAKE
variable to the version of make which is currently running (as best it
can determine it) and everyone should be invoking submakes using the
$(MAKE) variable.

But, perhaps something in your setup is confounding this normal
behavior.

You can try adding "VERBOSE=1" to your make invocation and look at the
way sub-makes are invoked and see if there's anything odd-looking about
it.

If that's not it, I'm not sure what the problem is but perhaps the
VERBOSE=1 will help diagnose it anyway.
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [cmake-developers] Eclipse CDT Managed build

[Paul Smith]

IMO the right place for managing relocatable builds is in the
compiler/linker, not in the build tool.

The compiler/linker should provide options that allow the output to be
relocatable regardless of the contents of the command line.  GCC for
example has -fdebug-prefix-map that will allow you to remove prefixes
from pathnames in debug sections of the output.  Unfortunately this is
only part of the solution since it doesn't help with __FILE__ (for
example).  Nevertheless this is the right direction, rather than
modifying the build system.


On Thu, 2017-01-26 at 14:01 +, Bøe, Sebastian wrote:
> Thank you for the warning and support. We would prefer to not
> maintain
> a fork, but I have not been able to find any other technology
> that is suitable.
> 
> For future reference. The intended use-case is for CMake to act 
> as an engine in an IDE project generator solution similar to the
> below
> solutions[0].
> 
> [0] 
> http://start.atmel.com/
> http://www.st.com/en/embedded-software/stm32cube-embedded-software.ht
> ml
> 
> 
> 
> -Original Message-
> From: Brad King [mailto:brad.k...@kitware.com] 
> Sent: 26. januar 2017 14:18
> To: Bøe, Sebastian 
> Cc: ben.boec...@kitware.com; cmake-developers@cmake.org
> Subject: Re: [cmake-developers] Eclipse CDT Managed build
> 
> On 01/26/2017 05:57 AM, Bøe, Sebastian wrote:
> > 
> > I will investigate relocatable builds, because in spite of this
> > not 
> > being trivial, I think CMake still comes out as the best suited
> > technology for my use-case.
> 
> We once had an option to produce relative paths in the build system
> and it was a never ending mess of bugs.  Eventually it was ripped
> out.
> It is unlikely we will accept changes to try to re-introduce such an
> option.
> 
> -Brad
> 
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [CMake] How to use a generated linker map with a shared library?

[Paul Smith]

On Tue, 2017-01-17 at 13:20 -0500, Paul Smith wrote:
> I wonder whether _fini and _init need to be exported in order to
> properly handle global ctor/dtor when the library is loaded/unloaded?
>  Hm.  I may need to do some experimentation here.

FWIW I tried some experimentation with both dynamic linking and
dlopen()/dlclose() methods of loading the shared library, and all my
global ctors and dtors appeared to be invoked as expected in both
situations regardless of whether the _fini and _init symbols were
public...

So I dunno.
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] How to use a generated linker map with a shared library?

[Paul Smith]

On Mon, 2017-01-16 at 09:07 -0700, clin...@elemtech.com wrote:
> > Yes, thanks for that info.  My situation is that I need to force ALL 
> > symbols to be private, even those from external static shared libraries 
> > that I'm linking in (whose symbols have global visibility by default).
> 
> Have you tried the "--exclude-libs ALL" linker option?  Using that
> should hide symbols from static libraries.

Yes, I looked at this.  I can't quite figure out what algorithm it uses
though.  It gives me _almost_ the same results as my linker script with
"local: *;", but not quite:

With the linker script if I use:

  nm libfoo.so | grep ' [A-TV-Z] '

I see only and exactly the symbols I marked as global in my code, and
nothing else as global.

If I use --exclude-libs=ALL then I see the symbols I marked as global
and _almost_ all the other symbols are local, but there some
exceptions; for example:

01f925a0 A __bss_start
01f925a0 A _edata
01fc0f4f A _end
0098c648 T _fini
0015b1b8 T _init

In addition, some C++ templated symbols (very complex) are public as
"W" (global weak symbols).  I don't know why.

I wonder whether _fini and _init need to be exported in order to
properly handle global ctor/dtor when the library is loaded/unloaded?
 Hm.  I may need to do some experimentation here.

I don't see any point in the static data symbols being public.
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] How to use a generated linker map with a shared library?

[Paul Smith]

On Sun, 2017-01-15 at 12:08 +1100, Craig Scott wrote:
> While not directly answering your question, it seems you may be trying
> to deal with symbol visibility. Are you aware of CMake's symbol
> visibility features? A good place to start would be the
> GenerateExportHeader module, the documentation for which does a
> reasonable job of showing how to use the visibility features CMake
> provides.

Yes, thanks for that info.  My situation is that I need to force ALL
symbols to be private, even those from external static shared libraries
that I'm linking in (whose symbols have global visibility by default).

So I need a linker script that contains (this is for GCC's ld):

  {
  global: ...;
  local: *;
  };

I need the "local: *;" to hide the external symbols, but to keep it from
hiding all my global symbols I need to list them all explicitly in the
global: section.

> Dealing with your question more directly, you may want to look at the
> TARGET form of add_custom_command() and in particular, the PRE_LINK
> keyword. See the Build Events section near the bottom of the page for
> the add_custom_command() docs.

Oh beauty!  That seems to be just what I need.  Thanks!
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

[CMake] How to use a generated linker map with a shared library?

[Paul Smith]

I'm really stuck: maybe someone can provide a hint.

I'm trying to create a shared library from a bunch of object files, and
use a linker script to mark almost all the symbols as local.  The tricky
thing is I'm auto-generating the linker script via a shell script that
examines the object files for my library (using readelf) to find global
symbols.

I basically need a process like this:

   1. Start with source files and a linker map generator shell script
   2. Compile all the code into object files
   3. If any file was recompiled (or the generator script) is modified, re-
  run the generator script to recreate the linker script
   4. If any file was recompiled or the linker script was recreated,
  rebuild the shared library, using the linker script.

In "make-ese" it would be trivial: something like:

  libmy.so: $(OBJECTS) link.script ;  ...

  link.script: $(OBJECTS) genlinkscript ;  ...

I simply can't figure out how to create something like this in CMake.

I have a custom command to create the linker script:

  add_custom_command(OUTPUT out.script
  COMMAND genlinkscript ${CMAKE_CURRENT_BINARY_DIR}
  DEPENDS <>
      VERBATIM)

And I have an add_library command to create the shared library:

  add_library(mylib SHARED foo.cpp foo.h out.script)

  set_property(TARGET mylib APPEND_STRING PROPERTY
LINK_FLAGS " -Wl,--version-script=out.script")

But what can my custom_command depend on, so that it's run AFTER all the
object files are created, but BEFORE the shared library is created?

I tried to do this using an OBJECT library, but see my previous post
that adding OBJECT libraries as dependencies of custom commands doesn't
work.

What can I do?  I'm happy with a solution that works only on Linux (I
can use if()/endif() to turn it off on my other platforms, which don't
use these linker scripts anyway).
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

[CMake] cmake 3.7.2: add_custom_command can't DEPEND on OBJECT library?

[Paul Smith]

If I create an OBJECT library:

  add_library(libIface OBJECT iface.cpp)

Then I create a custom command that depends on this:

  add_custom_command(OUTPUT out.map
      COMMAND touch out.map
      DEPENDS libIface
      VERBATIM)

It doesn't work: the dependency is missing so when I edit the iface.cpp
file the custom command is not run.  I'm using the Makefile generator,
on Linux, and if I look at the generated makefile it's obvious that
there's nothing there representing the OBJECT library:

  out.map:
@$(CMAKE_COMMAND) -E ... "Generating out.map"
touch out.map

The documentation for add_custom_command() clearly says that DEPENDS can
specify "any target (created by the ... add_library() command)".

Is there something missing from the docs that should say it doesn't work
with OBJECT libraries, or is this a bug in cmake?


Repro:


$ cat CMakeLists.txt
cmake_minimum_required(VERSION 3.5)
project(MapTest)

add_library(libIface OBJECT iface.cpp)

add_custom_command(OUTPUT out.map
COMMAND touch out.map
DEPENDS libIface
VERBATIM)

add_custom_target(libIfaceMap DEPENDS out.map)

add_library(iface SHARED $ out.map)

$ touch iface.cpp

$ cmake .

$ make
Scanning dependencies of target libIface
[ 33%] Building CXX object CMakeFiles/libIface.dir/iface.cpp.o
[ 33%] Built target libIface
[ 66%] Generating out.map
Scanning dependencies of target iface
[100%] Linking CXX shared library libiface.so
[100%] Built target iface

$ touch iface.cpp

$ make
Scanning dependencies of target libIface
[ 33%] Building CXX object CMakeFiles/libIface.dir/iface.cpp.o
[ 33%] Built target libIface
[ 66%] Linking CXX shared library libiface.so
[100%] Built target iface


Note that in the last step the "out.map" file was not recreated even
though iface.cpp was modified.
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

[CMake] Linker flags on all except a couple of programs

[Paul Smith]

I have a CMake-based build that creates about 170 binaries (most of them
are individual unit test programs).

I have set the CMAKE_EXE_LINKER_FLAGS to a set of flags I wanted on all
the binaries.

Now it turns out that I need to remove, or not set, one specific flag on
a small number (like 5) of these binaries, but I still want it set on
all the others.  Unfortunately for this flag there's no "turn it off"
extra flag I can add to the end of the list of flags: I have to actually
remove the flag itself.

What's the cleanest/simplest way to accomplish this?  I don't really
want to modify my cmake files to add an explicit set_target_property()
to all 165 binaries that I _do_ want to have this flag set on, just so I
can avoid calling it on the 5 binaries I don't.  I want to add something
particular to the 5 "oddball" binaries, instead, to override these
values.

But I can't seem to come up with a way to remove a flag from a global
list like this, just for one (or a few) targets.


Any hints?
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] cmake 3.5.2 Xcode generator bug

[Paul Smith]

On Fri, 2016-05-20 at 14:34 -0400, Paul Smith wrote:
> Just discovered a bug in the Xcode generator; this works fine with
> Makefile generator (on OSX or Linux) and Visual Studio, but fails on
> Xcode:

Meh.  Looks like this is documented in add_library():

> Some native build systems may not like targets that have only object 
> files, so consider adding at least one real source file to any target 
> that references $.

Unfortunately for me, I really have to have all the object files in the
OBJECT library (see my previous email about generating linker map files
based on the contents), and there're no other files to add into the
library.

Sigh.
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

[CMake] cmake 3.5.2 Xcode generator bug

[Paul Smith]

Just discovered a bug in the Xcode generator; this works fine with
Makefile generator (on OSX or Linux) and Visual Studio, but fails on
Xcode:

  $ cat CMakeLists.txt
  cmake_minimum_required(VERSION 3.5)
  project(BadXcode)
  add_library(obj OBJECT foo.cpp)
  add_library(shared SHARED $)

  $ touch foo.cpp

  $ mkdir obj

  $ cd obj

  $ cmake -G Xcode ..

  $ cmake --build .

The build succeeds, but it never creates the libshared.dylib file:

  $ find . -name lib\*
  ./BadXcode.build/Debug/obj.build/Objects-normal/libobj.a

I'm not sure why we're creating a .a here, when we're making an OBJECT
library, but whatever... the main thing is there's no libshared.dylib:

  $ find . -name \*.dylib

  $ find . -name \*shared\*
  ./BadXcode.build/Debug/shared.build
  ./CMakeScripts/shared_postBuildPhase.makeDebug
  ./CMakeScripts/shared_postBuildPhase.makeMinSizeRel
  ./CMakeScripts/shared_postBuildPhase.makeRelease
  ./CMakeScripts/shared_postBuildPhase.makeRelWithDebInfo

If I use the Makefile generator instead, it works as expected:

  $ rm -rf *

  $ cmake ..

  $ cmake --build .
  Scanning dependencies of target obj
  [ 50%] Building CXX object CMakeFiles/obj.dir/foo.cpp.o
  [ 50%] Built target obj
  Scanning dependencies of target shared
  [100%] Linking CXX shared library libshared.dylib
  [100%] Built target shared

  $ find . -name lib\*
  ./libshared.dylib
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] Argh! Thwarted at every turn!

[Paul Smith]

On Fri, 2016-05-20 at 11:58 -0400, Paul Smith wrote:
> This is not nice but it does work...

Gah!  The last of my problems can be solved with add_dependencies().
Somehow I didn't see this and was looking through all the target
properties with set_properties() to find a way to add a dependency...
sigh.

Well, if anyone has a simpler way to solve the basic problem
(generating a link map which requires the .o files that will be used to
construct the shared library as input) I'm still interested.

So in makefile-ese I want to do something like this:

  mylib.so: $(OBJFILES) linkmap lib1 lib2 lib3
  $(CXX) ... -o $@ -Wl,--version-script=linkmap ...

  linkmap: $(OBJFILES)
  genlinkmap -o $@ $^

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

[CMake] Argh! Thwarted at every turn!

[Paul Smith]

I'm using CMake 3.5.2 generating for Linux / OSX / Visual Studio.

I'm creating a shared library.  This shared library is constructed
mostly from other libraries (which are also built in other directories
by this cmake setup).

I have been doing this for a long time and it worked fine:

  add_library(mylibrary SHARED foo.cpp foo.h bar.cpp bar.h ...)
  target_link_libraries(mylibrary PRIVATE mylib1 mylib2 VerData ...)

Fine.  Now the problem is that I need to generate a link map and I have
a script that parses the object files in mylibrary to create the link
map (the link map is only created/used on Linux of course).

Well, I can't find any way to get a listing of the .o files that are
generated by compiling the .cpp files in the add_library() call above.

So, instead I decided to turn those files into a library, themselves,
then I can use $ with my add_custom_command()
that runs the link map generator script.

However, then I have something like this:

  add_library(libIntern STATIC foo.cpp foo.h bar.cpp bar.h ...)
  add_library(mylibrary SHARED linkmap)
  target_link_libraries(mylibrary PRIVATE libIntern mylib1 mylib2 VerData ...)

  add_custom_command(OUTPUT linkmap COMMAND genmap $ ...)
  set_property(TARGET mylibrary APPEND PROPERTY LINK_DEPENDS linkmap)

But this doesn't work because since libIntern is a static library only
the symbols that are referenced somewhere else are included, and no
symbols are actually referenced anymore since there are no source files
in the library.

So then I thought, well, I'll use an OBJECT library for the internal
one:

  add_library(libIntern OBJECT foo.cpp foo.h bar.cpp bar.h ...)
 
add_library(mylibrary SHARED $)
 
target_link_libraries(mylibrary PRIVATE mylib1 mylib2 VerData ...)

  add_custom_command(OUTPUT linkmap COMMAND genmap
$ ...)
  set_property(TARGET mylibrary APPEND
PROPERTY LINK_DEPENDS linkmap)

That worked for mylibrary... but of course I can't use $ anymore 
with an OBJECT library.  And I can't use $ in my custom 
command either.  In fact I can't find any way to get a list of the object files 
that are part of libIntern.

So then I finally said "whatever" and created another static library out of the 
OBJECT library, just for use with my linkmap generating script:

  add_library(libIntern OBJECT foo.cpp foo.h bar.cpp bar.h ...)
  add_library(mylibrary SHARED linkmap $)
  target_link_libraries(mylibrary PRIVATE mylib1 mylib2 VerData ...)

  add_library(internStatic STATIC $)
  add_custom_command(OUTPUT linkmap COMMAND genmap $ 
...)
  set_property(TARGET mylibrary APPEND PROPERTY LINK_DEPENDS linkmap)

This is not nice but it does work...

Except for one thing.  Some of the files in foo.cpp ... depend on a header file 
which is generated as part of the build, using a separate custom command, and I 
handle this by compiling a little static library that needs this header file:

  add_custom_command(OUTPUT verdata.h COMMAND ...)
  set_source_files_properties(verdata.h PROPERTIES HEADER_FILE_ONLY TRUE)
  add_library(VerData STATIC Version.cpp Version.h)
  set_property(SOURCE Version.cpp APPEND PROPERTY OBJECT_DEPENDS verdata.h)

Then the VerData library is added to target_link_libraries() everywhere.  
Coming from a strictly makefile background it doesn't seem to me that this 
should be sufficient, but in fact it appears to work.

But in my new setup you can see that the OBJECT library no longer depends on 
the VerData library, which means that the auto-generated header file is not 
ensured to be created before the compilation of the objects in libIntern.  And 
in fact, I get compilation errors because the verdata.h file is not generated 
before these compilations (particularly in Xcode, for some reason).

And, I don't know how to solve this problem: I can't find any way to add a new 
prerequisite to the the libIntern OBJECT library to ensure that the VerData 
library is built first.  I can't add a target_link_libraries() to an OBJECT 
library.  I sure don't want to have to explicitly set the OBJECT_DEPENDS 
property on every single source file!


All I want to do is call a script passing the object files to generate a link 
map before I create my shared library, and I've gone all the way down this 
rabbit hole...

Help!
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] in source makefile / helper script that enables building out of source?

[Paul Smith]

On Wed, 2016-05-11 at 09:06 -0500, Steve Lorimer wrote:
> I am aware of being able to do in-source builds, but would like to
> continue to reap the benefits of out-of-source builds whilst being
> able to build from in-source

Make a shell function or shell script to run your build, that does the
cd to the build directory and starts the build.
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [cmake-developers] Code style auto-formatting

[Paul Smith]

On Mon, 2016-05-09 at 14:17 -0400, Brad King wrote:
> > What is the rationale for "ColumnLimit: 79"? To make a line fit on old
> > school terminals, 80 should be OK. To make a diff or an email response
> > fit on old school terminals, two extra spaces are reserved. That leads
> > to a column limit of 78. Where does 79 come from?
> 
> That has been CMake's limit for a long time.  Since we're changing the
> style anyway we might as well go with the more common 80 chars that is
> default in the Mozilla style.

Not to say whether or not this should be changed, but FYI the 79 comes
from this set of facts:

 * Traditional terminals are 80 chars wide
 * Editors and viewers that do line-wrapping use the last character of
   the line to specify whether there was a wrap, otherwise you can't
   tell if the line is wrapped or there's a newline.

So a line that is exactly 80 characters long would look like this in
such a viewer:

this line...is 80 chars lon\
g
and this isn't


Hence the restriction to 79 chars to avoid that wrap.  Also, some kind
-of-broken terminals used to automatically scroll the window if you
wrote a character to the bottom-right-most character (line 24 / char
80).
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] Git for windows patch

[Paul Smith]

On Fri, 2016-01-15 at 11:37 -0500, Jean-Christophe Fillion-Robin wrote:
> > The existence of \bin is there only for backward
> -compatibility
> 
> I guess we could also add "Git/usr/bin" to the suffixes so that it
> prefer newer version first ?
> 
> PATH_SUFFIXES Git/usr/bin Git/cmd Git/bin 

I'm not sure which command you're looking for?

git.exe exists only in Git/bin (old-style) and Git/cmd.  Where both
exist they'll have exactly the same version of git.exe in them.

I think using Git/cmd only to find git.exe is fine; I'm pretty sure
it's always existed there even in older releases of Git for Windows, an
d will continue to do so going forward.

You definitely don't need Git/usr/bin unless you want to find all the
UNIX tools.  Git.exe is not there.
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] Git for windows patch

[Paul Smith]

On Fri, 2016-01-15 at 10:05 -0500, Shawn Waldon wrote:
> Looking at the git installation, there is another executable
> "C:\Program Files (x86)\Git\cmd\git.exe", but I have never pointed
> CMake at that one.  What is the difference between the two?  I can
> change the patch to use the other one, but I'd like to understand why
> it is necessary.

There is no difference between them.  When you install Git for Windows
the installer gives a choice of three different ways to set up %PATH%.

One way is to not add anything to %PATH%: then git is only available
from within the Git bash shell not from within command.com shell.

The second way is to make git, only (plus a few helpers like gitk,
start-ssh-agent, etc.) available on %PATH%: then git is available from
command.com but none of the other UNIX tools like find, diff, etc. are
available from command.com (only from Git shell).  In this install
method the \cmd directory is added to %PATH%.

The last way is to allow git plus all the ming32 versions of UNIX tools
that come with Git to be available to command.com.  In this install
method both \cmd AND \usr\bin are added to %PATH%.

The existence of \bin is there only for backward
-compatibility, because some people coming from older versions of Git
for Windows might be referencing it.  It shouldn't be used anymore by
modern installs (it contains bash.exe and sh.exe both of which are in
\usr\bin, and git.exe which is in \cmd).
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

[CMake] CMake doesn't preserve command line overrides on restart

[Paul Smith]

If my compiler changes between the last invocation of cmake and this
one, then cmake will restart itself; this part works fine.  The problem
is that if I've invoked cmake with some command line overrides, they are
lost when I restart.  For example if I have in my makefile:

  set(BUILDNUM "0" CACHE STRING "Build Number")
  message(STATUS "Build number = ${BUILDNUM}")

by default this is 0, so when developers build locally the build number
is 0.  When cmake is invoked through our CI build system, it is run like
this:

  cmake -DBUILDNUM=125 .

or whatever the current build number is for that build.

However, if the compiler has changed and we need to restart the build,
this breaks:

  -- Build number = 125
  -- Configuring done
  You have changed variables that require your cache to be deleted.
  Configure will be re-run and you may have to reset some variables.
  The following variables have changed:
  CMAKE_C_COMPILER= /new/bin/x86_64-rh55-linux-gnu-gcc
  CMAKE_CXX_COMPILER= /new/bin/x86_64-rh55-linux-gnu-g++

  -- Build number = 0
  -- Configuring done
  -- Generating done
  -- Build
files have been written to: /home/psmith/src/cmake/restart

Note that when cmake re-runs itself the command line setting for BUILDNUM has 
been lost and it reverts to the default value.

To me this is a bug... thoughts?

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] Parallel jobs failed for cmake

[Paul Smith]

On Mon, 2015-12-14 at 09:34 +0300, Igor Sobinov wrote:
> So, If I write in makefile
> 
> 
> build_release: $(RELEASE_DIR)
> @cd $(RELEASE_DIR); $(MAKE) release
> 
> I got an error
> 
> Also if I write
> build_release: $(RELEASE_DIR)
> $(MAKE) release -C  $(RELEASE_DIR)
> 
> I got an error too
> 
> But this is successfull command:
> # cd $RELEASE_DIR; make release -j10
> 
> Why make doesn't support jobs for subdirs?

All three of these work for me, so it must be something else in your
makefile that you haven't shown us that's causing the problem.  Can you
provide a SSCCE (http://sscce.org/)?

As Bill points out this is a make issue, NOT a cmake issue.  I recommend
you re-start this thread with all details (operating system, version of
make, SSCCE, etc.) on the help-m...@gnu.org mailing list rather than
here.

I'll offer one possible suggestion, first: you haven't by any chance
changed the SHELL variable in your external makefile to use csh, have
you?

SHELL = /bin/csh

(or tcsh either).  Because if you have, that's the problem.  Csh is a
terrible shell for many reasons but in particular it cannot be used as
the shell for makefiles, if you want the jobserver feature to work.

> core::
> +(cd core; make)
> 
> With this, GNU Make is able to distribute the jobs between the
> subdirectories. (I have a number of such targets in my main Makefile.)

Bill's comment, that you should use $(MAKE) and never plain "make", is
correct.  It's better to use $(MAKE) for many reasons, only some of
which are handled by prefixing the recipe with "+".
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [cmake-developers] Code style auto-formatting

[Paul Smith]

On Tue, 2015-11-17 at 08:14 +, Stuermer, Michael SP/HZA-ZSEP wrote:
> In short, there is no fully automated style checking. If someone would
> come up with a tool & configuration I would love to use this. So far I
> tested astyle and the C++ edition of ReSharper (unfortunately quite
> expensive).

We've used uncrustify with excellent results in the past, FWIW.

It is a major hassle though.  We did a complete code reformat with a
well-defined process, and then had all developers apply reformatting to
their personal branches using a particular set of steps to minimize the
insanity.

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

[CMake] ARGVx inherited by sub-functions?

[Paul Smith]

Is this a known thing, or a bug (I'm using cmake 3.1.0):

I create this CMakeLists.txt:

  cmake_minimum_required(VERSION 3.1.0)
  project(ArgTest)

  function(FOO one two)
message(STATUS extra args are ${ARGN})
message(STATUS third arg is ${ARGV2})
  endfunction()

  function(BAR one)
FOO(${one} TWO)
message(STATUS do something with ${ARGN})
  endfunction()

  BAR(ONE N1 N2 N3 N4)

Note how I invoke BAR() with 5 arguments, but BAR invokes FOO with only
two arguments.  I would expect that the third argument ${ARGV3} would be
empty in function FOO.

However, when I run cmake on this file it shows:

  -- extra args are
  -- third arg is N2
  -- do something with N1;N2;N3;N4

So the ARGN for function FOO is correct (nothing there) but FOO has
inherited the extra ARGVx arguments beyond the first two, that I
passed to function BAR!

That's rather unexpected.  Bug or feature?

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

[CMake] Why does changing -G not change generators?

[Paul Smith]

We have a situation where people are sometimes wanting to switch between
different generators: from Xcode to Unix Makefiles, or from Visual
Studio 2010 to Visual Studio 2012, etc.

If they have an already-configured workspace then run cmake -G with a
different generator, it appears to be a no-op: no error is generated but
no changes are made and the previous generator is still used.

This doesn't seem right to me... shouldn't giving a new generator type
on the command line change the output for the new generator?  I'm using
CMake 3.1.0... maybe this has changed since?

Cheers!

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] Long command lines

[Paul Smith]

On Mon, 2015-06-29 at 13:08 +0200, SF Markus Elfring wrote:
  unfortunately i dont quite understand what you mean with your
 tool.
 
 How many efforts would you like to invest so that limitations
 around software like a fortran preprocessor can be circumvented?
 
 http://www.cmake.org/Wiki/CMake_FAQ#How_can_I_avoid_the_error_.22Arg_list_too_long.22_when_running_make.3F

Just to be clear, this isn't a problem with make per se.  The operating
system itself has a limitation on the amount of data in the environment
(which consists of both environment variables and command line
arguments) that can be passed from one process to its child process.  No
program, whether it's make or something else like the shell, can exceed
that limit.

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] Where do all the extra clang flags come from in Xcode?

[Paul Smith]

On Mon, 2015-05-18 at 12:32 +0200, Ruslan Baratov via CMake wrote:
 This table tells you what attribute you need to set to disable/enable
 specific warning.

I see, so these are CMake attributes?  That wasn't clear to me.  I
thought they were attributes of Xcode.

I guess my basic question is, why are all these extra flags to disable
and enable various warnings set in the Xcode generator?  I expected it
would work like the makefile generator, where if you don't set any flags
in CMakeLists.txt then you don't get any warnings enabled (or explicitly
disabled).  It surprises me that when I take the same CMakeLists.txt
file and use a Makefile generator and an Xcode generator, I get very
different compile lines.

And secondarily, is there any way to get the Xcode generator to work
like the Makefile generator, where only the warning flags I explicitly
defined in my CMakeLists.txt file are added to the compile/link lines
and no others?

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] Where do all the extra clang flags come from in Xcode?

[Paul Smith]

On Sun, 2015-05-17 at 14:43 +0200, Ruslan Baratov via CMake wrote:
 As far as I know extra flags set by Xcode itself. You can use 
 XCODE_ATTRIBUTE_* target properties to enable/disable warnings. This 
 table can be helpful: 
 https://github.com/ruslo/leathers/wiki/List#xcodeclang-table

Thanks for your reply... but I don't quite understand what this table is
telling me.

As mentioned, these builds are performed on build servers running OSX,
where basically the code is retrieved via Git, then cmake is run, then
cmake -build is run (which invokes xcodebuild via the command line), all
using SSH commands from a build control server.  At no time is Xcode
itself invoked.

So, if the properties you describe are Xcode settings that need to be
tweaked then do you know if there is some command-line way to do it,
that I could encode into my build scripts for example?

Thanks!

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

[CMake] OSX xcodebuild not rebuilding objects?

[Paul Smith]

Has anyone else run into errors rebuilding objects using the Xcode
generator?  I imagine it would be a bug in xcodebuild, not cmake.  We've
been using incremental builds, rather than clean builds, for years with
cmake on GNU/Linux (make), OSX (Xcode), and Windows (MSVC) and this is
the first time I've ever seen this.

One of our C++ unit tests got a bus error on OSX and while debugging it
became clear that one of our object files was not rebuilt after a header
file had changed (obviously very bad).

Looking at the build directory, the object file was definitely NOT
rebuilt when it should have been: the object file's time-last-modified
was April 29, the object file's .d file contained the fully-qualified
path to the header file in question, and the time-last-modified on the
header file was May 12.  The build log shows other object files being
rebuilt, but not this one.  There's absolutely nothing special about
this file: it's just a standard C++ source file and appears in a list of
similar C++ files in my CMakeLists.txt file.

I've never seen this happen before, has anyone else run into it?  This
makes me very concerned!

$ cmake --version
cmake version 3.1.0

$ xcodebuild -version
Xcode 6.2
Build version 6C131e

$ sw_vers
ProductName:Mac OS X
ProductVersion: 10.9.5
BuildVersion:   13F1066


-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

[CMake] Where do all the extra clang flags come from in Xcode?

[Paul Smith]

I was comparing the command line used when we choose an Xcode generator
on our OSX systems, vs. the command line used when we choose a Makefile
generator.  We certainly have nothing in our CMakeLists.txt which sets
compiler flags based on the type of generator, only based on the type of
compiler (GCC, Clang, etc.)

But, when I look at the compiler and flags used by the Makefile
generator it uses /usr/bin/c++ (which is clang++ underneath) and it's
basically only the the compiler flags that we provided.

When I look at the compiler and flags used by the Xcode generator, not
only does it use a different path to the compiler
(/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang
 -x c++) but, more concerning (because I assume that /usr/bin/clang++ 
eventually gets down to the same actual compiler as above) but it contains a 
huge number of extra flags, for example it appears to disable all sorts of 
warnings (that we don't want disabled):  -Wno-missing-prototypes, 
-Wno-return-type, -Wno-non-virtual-dtor, -Wno-overloaded-virtual, etc. etc.

This means people who build on OSX using Makefile generators see extra
warnings that people who build on OSX using Xcode don't see.

Where are these extra flags all coming from?  Is it from Xcode itself
somehow?  Can I keep them from being added?  I don't want peoples'
personal Xcode settings to disable warnings during compilation!

Note these are build servers and so no one is actually invoking Xcode:
we log in via SSH, use cmake to generate the Xcode project files, then
use cmake -build (which runs xcodebuild) to run the build itself.

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] How to build a target on install (only)?

[Paul Smith]

On Mon, 2015-02-16 at 09:55 -0500, David Cole wrote:
 Ah ha! Back to the simpler approach with install(CODE!
 
 Good idea, Nils.
 
 Then you just need a stamp/sentinel file associated with running the
 operation, and you can check it against your input.

Aha, that works well.  I don't need a sentinel file since I can just
test against one of the files that dsymutil generates.

And, I discovered I can have a multi-line CODE just by adding newlines
into the string, so that works well.

Nice!  Thanks all!

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] How to build a target on install (only)?

[Paul Smith]

On Sun, 2015-02-15 at 18:26 -0600, Iosif Neitzke wrote:
 For conditional file install, you could try something like cmake -E
 copy_if_different.

That won't work; I don't have any files to copy.  What I want is to run
the dsymutil command during install only, not during the normal build
(because it's slow), but only if the binary that was installed has
changed.

copy_if_different won't help here.

 On Sun, Feb 15, 2015 at 1:59 PM, Paul Smith p...@mad-scientist.net wrote:
install(CODE message(STATUS \Creating dSYM for ${target} in ${dir}\))
install(CODE execute_process(COMMAND dsymutil \${dir}/${target}\ 
  OUTPUT_QUIET))



-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

[CMake] How to build a target on install (only)?

[Paul Smith]

In my Mac OSX builds I want to run dsymutil to create .dSYM debug
contents.  However, this is very slow so I don't want to do it during
normal builds (where it's not needed because I have all the object
files), I only want it to be done during the install step.

I can create an add_custom_command() to run dsymutil easily enough,
something like:


  function(stagedebug target dir)
  if(APPLE)
  set(destfile ${dir}/${target}.dSYM/Contents/Info.plist)
  add_custom_command(OUTPUT $destfile
  COMMAND dsymutil ${dir}/${target}
  MAIN_DEPENDENCY ${target}
  COMMENT Staging dSYM for ${target} to ${dir}
  VERBATIM)

  # Now what?
  endif
  endfunction()


but I have no idea how to hook this into the install step.  I don't see
anything in the install() command that lets me specify a target to be
run, it just seems to be able to copy files.

What am I missing?

Thanks!
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] Are CMAKE_CXX_FLAGS supposed to go on the link line?

[Paul Smith]

I didn't get a response to the question below.  I've since reproduced
this with a simple test case; maybe someone can let me know why this
difference appears and how I should handle it?  I'm using cmake 3.1.0:

Sample CMakeLists.txt:

  $ cat CMakeLists.txt EOF
  cmake_minimum_required(VERSION 3.1.0)
  project(FlagTest)
  set(CMAKE_CXX_FLAGS -pthread)
  add_executable(foo foo.cpp)
  EOF

  $ echo 'int main(int argc, char**argv) { return 0; }'  foo.cpp

On MacOSX with Xcode installed, I see the following behavior:

  $ cmake -G Xcode .  cmake --build . 21 | tee xc.out

In the output I see that the -pthread flag DOES appear on the compile
line for foo.o, but DOES NOT appear in the link line for foo:

  $ grep pthread xc.out
  /.../clang -x c++ ... -pthread ...  -c /.../foo.cpp -o /.../foo.o

This is correct for clang, which does not want -pthread on the link line
(unlike GCC, which wants it in both places).  Now, I clean that up and
try with the Makefile generator, and I see the following behavior:

  $ cmake -G 'Unix Makefiles' .  cmake --build . -- VERBOSE=1 21 | tee 
mk.out
  clang: warning: argument unused during compilation: '-pthread'

Now in this case we can see that the -pthread flag was added to BOTH the
compile and the link line:

  $ grep pthread mk.out
  /usr/bin/c++ -pthread -o .../foo.cpp.o -c .../foo.cpp
  /usr/bin/c++ -pthread .../foo.cpp.o -o foo
  clang: warning: argument unused during compilation: '-pthread'

This warning is totally bogus: it really means unused during LINKING,
but anyway: I'm not sure what to do to get rid of this warning: I need
to support both Xcode and Makefiles on MacOSX (and Makefiles on Linux as
well as both GCC and Clang).

Is the intent that CMAKE_CXX_FLAGS only ever appear on the compile line?
Or should it appear on both the compile and link lines?  Is there an
equivalent flag to CMAKE_EXE_LINKER_FLAGS that always applies only to
compile lines, in all generators?  Do we just have to continue to
bastardize add_definitions() for this, maybe?


On Thu, 2015-01-08 at 18:52 -0500, Paul Smith wrote:
 If I'm on OSX, then when I set CMAKE_CXX_FLAGS and do not set
 CMAKE_EXE_LINKER_FLAGS, for example, and I use the Xcode generator,
 then
 I see:
   * CMAKE_CXX_FLAGS show up on the compilation line
   * CMAKE_CXX_FLAGS do NOT show up in the linker line
 
 On the other hand if I'm on OSX and I use the Unix Makefiles
 generator,
 then I see:
   * CMAKE_CXX_FLAGS show up on the compilation line
   * CMAKE_CXX_FLAGS ALSO show up in the linker line
 
 I assume the Xcode output is correct and the makefile output (with
 CMAKE_CXX_FLAGS in both) is not correct... but there's nothing I can
 find in the docs that says this explicitly.
 
 I've printed the contents of the CMAKE_CXX_FLAGS and
 CMAKE_EXE_LINKER_FLAGS at the end of my CMakeLists.txt and they're
 just
 what I expect.  It's just that the link line has extra flags, when
 invoked from make.


-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] VS2012 builds using v3.1.0 are a lot slower than v2.8.12

[Paul Smith]

On Tue, 2015-01-20 at 16:02 -0500, Paul Smith wrote:
  I think devenv is used instead of msbuild when the solution has 
  fortran projects.
 
 I certainly don't have any Fortran projects--!!

I think I figured it out: on our build servers we don't delete
everything and start over from scratch all the time (only for our
official release builds).

We recently upgraded our cmake from 2.8.12.2 to 3.1.0 and I think that
the systems where we were seeing this problem had CMakeCache.txt files
left over from when we were using CMake 2.8.12.2, and those files had
CMAKE_MAKE_PROGRAM set (we never set it by hand, even back then, but
maybe the older version of cmake added it to the cache on its own?) to
devenv.

Certainly when I went in and looked at CMakeCache.txt that value was set
to devenv.exe.  If I regenerated the CMakeCache.txt from scratch, it
was no longer set.

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] VS2012 builds using v3.1.0 are a lot slower than v2.8.12

[Paul Smith]

On Tue, 2015-01-20 at 21:57 +0100, Nils Gladitz wrote:
 On 20.01.2015 21:40, Paul Smith wrote:
  Where can I go to find out more about how cmake --build chooses whether
  to use msbuild vs. devenv?  It has to be something more complicated than
  just the generator used, otherwise all of these systems would use
  msbuild.
 
 I think devenv is used instead of msbuild when the solution has fortran 
 projects.

I certainly don't have any Fortran projects--!!

All C/C++.

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] VS2012 builds using v3.1.0 are a lot slower than v2.8.12

[Paul Smith]

 Am 20. Januar 2015 14:54:26 MEZ, schrieb David Cole via CMake
 cmake@cmake.org:
 If you open the Tools  Options dialog in Visual Studio, and
 navigate to the Projects and Solutions  Build and Run tab, what is
 your maximum number of parallel project builds value?
 
 For maximum parallel build capability, it should be set to the same
 as the number of cores you have.

On Tue, 2015-01-20 at 17:30 +0100, Hendrik Sattler wrote:
 but msbuild does not use this setting from VS, only devenv does.

So, I've discovered we're having this problem as well... on 3 of our 6
Windows build servers!!

Looking at the logs I can see that on systems where it's slow, cmake
--build is choosing to use msbuild (and we don't have any added flags
to have it run in parallel).

On the other three systems where the build is fast, cmake --build is
choosing to use devenv (and is building in parallel by default).

All these systems have Visual Studio 2010 and Visual Studio 2008
installed, but we invoke the builds on them identically in all cases
(and these builds are using a generator of 'Visual Studio 10 x64').

Where can I go to find out more about how cmake --build chooses whether
to use msbuild vs. devenv?  It has to be something more complicated than
just the generator used, otherwise all of these systems would use
msbuild.


FYI, I'm using CMake 3.1.0.

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

[CMake] Are CMAKE_CXX_FLAGS supposed to go on the link line?

[Paul Smith]

It seems different generators are handling this differently, which is
frustrating (I've tried with both CMake 3.1.0 and 2.8.12.2)... or else
there's something very bizarre about my cmake files.

The new doc layout looks nice, but it really needs an infusion of
detail.  Here's the doc for CMAKE_CXX_FLAGS:

http://www.cmake.org/cmake/help/v3.1/variable/CMAKE_LANG_FLAGS.html

which isn't so helpful for my question :-).

If I'm on OSX, then when I set CMAKE_CXX_FLAGS and do not set
CMAKE_EXE_LINKER_FLAGS, for example, and I use the Xcode generator, then
I see:
  * CMAKE_CXX_FLAGS show up on the compilation line
  * CMAKE_CXX_FLAGS do NOT show up in the linker line

On the other hand if I'm on OSX and I use the Unix Makefiles generator,
then I see:
  * CMAKE_CXX_FLAGS show up on the compilation line
  * CMAKE_CXX_FLAGS ALSO show up in the linker line

I assume the Xcode output is correct and the makefile output (with
CMAKE_CXX_FLAGS in both) is not correct... but there's nothing I can
find in the docs that says this explicitly.

I've printed the contents of the CMAKE_CXX_FLAGS and
CMAKE_EXE_LINKER_FLAGS at the end of my CMakeLists.txt and they're just
what I expect.  It's just that the link line has extra flags, when
invoked from make.

Can anyone else reproduce this?

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

[CMake] [3.1.0] [PATCH] CMP0054 in CMakeDetermineCXXCompiler.cmake

[Paul Smith]

Hi all.  I'm testing an upgrade to CMake 3.1.0 (from 2.8.12.2) and
seeing a weird warning, but ONLY on Windows; it works fine on GNU/Linux
and OSX:

  -- The C compiler identification is MSVC 16.0.40219.1
  -- Check for working C compiler using: Visual Studio 10 2010 Win64
  -- Check for working C compiler using: Visual Studio 10 2010 Win64 -- works
  -- Detecting C compiler ABI info
  -- Detecting C compiler ABI info - done
  -- The CXX compiler identification is MSVC 16.0.40219.1
  CMake Warning (dev) at 
obj/REPOS/nuo3rdparty/common/cmake/share/cmake-3.1/Modules/CMakeDetermineCXXCompiler.cmake:106
 (if):
Policy CMP0054 is not set: Only interpret if() arguments as variables or
keywords when unquoted.  Run cmake --help-policy CMP0054 for policy
details.  Use the cmake_policy command to set the policy and suppress this
warning.

Quoted variables like MSVC will no longer be dereferenced when the policy
is set to NEW.  Since the policy is not set the OLD behavior will be used.
  Call Stack (most recent call first):
CMakeLists.txt:26 (enable_language)
  This warning is for project developers.  Use -Wno-dev to suppress it.

  -- Check for working CXX compiler using: Visual Studio 10 2010 Win64
  -- Check for working CXX compiler using: Visual Studio 10 2010 Win64 -- works

If I apply the attached patch it seems to fix the problem...?


diff --git a/Modules/CMakeDetermineCXXCompiler.cmake b/Modules/CMakeDetermineCXXCompiler.cmake
index 893c454..ea3a910 100644
--- a/Modules/CMakeDetermineCXXCompiler.cmake
+++ b/Modules/CMakeDetermineCXXCompiler.cmake
@@ -103,12 +103,12 @@ if(NOT CMAKE_CXX_COMPILER_ID_RUN)
   CMAKE_DETERMINE_COMPILER_ID(CXX CXXFLAGS CMakeCXXCompilerId.cpp)
 
   # Set old compiler and platform id variables.
-  if(${CMAKE_CXX_COMPILER_ID} MATCHES GNU)
+  if(CMAKE_CXX_COMPILER_ID MATCHES GNU)
 set(CMAKE_COMPILER_IS_GNUCXX 1)
   endif()
-  if(${CMAKE_CXX_PLATFORM_ID} MATCHES MinGW)
+  if(CMAKE_CXX_PLATFORM_ID MATCHES MinGW)
 set(CMAKE_COMPILER_IS_MINGW 1)
-  elseif(${CMAKE_CXX_PLATFORM_ID} MATCHES Cygwin)
+  elseif(CMAKE_CXX_PLATFORM_ID MATCHES Cygwin)
 set(CMAKE_COMPILER_IS_CYGWIN 1)
   endif()
 endif()
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] Help with Policy CMP0026 (disallow LOCATION target property)

[Paul Smith]

On Mon, 2014-12-29 at 02:03 +, Fraser Hutchison wrote:
 I'd have thought the following replacement would work the same:
 
   function(stageobj target dir)
   add_custom_target(stage_${target} ALL
   COMMAND ${CMAKE_COMMAND} -E make_directory ${DESTDIR}/${dir}
   COMMAND ${CMAKE_COMMAND} -E copy_if_different 
 $TARGET_FILE:${target} ${DESTDIR}/${dir}
   COMMENT Staging ${target} to ${DESTDIR}/${dir}
   VERBATIM)
   add_dependencies(stage_${target} ${target})
   endfunction()

Sorry for the delayed reply, I was on holiday.

Yes, this will work although it means I get the Staging ... message
for every staged file every time I build (even if it doesn't actually
copy unless different); I think that's why I used the other method.

I bit the bullet and changed my rules to build directly into the staging
area rather than copying them afterward.  Since I already went through
the pain I'd just as soon not go back again now :-), so I'm all set I
think.

Thanks all!

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] Help with Policy CMP0026 (disallow LOCATION target property)

[Paul Smith]

On Tue, 2014-12-23 at 16:59 -0500, David Cole wrote:
 Are you sure there's a problem using TARGET_FILE in your original
 context?

 You should be able to use that in a custom command in your custom
 stage_tgt target...
 
 You have to give the name of the target for the TARGET_FILE generator
 expression, so it should work for any target that cmake knows about.
 
 Can you point to a simplified reproducible case where this does not
 work?
 
 Maybe there's some other complication in your real project that is
 making it seem like it's not working but I think it should. Can
 you send us any code?

Thanks for the reply David.

The complication is that the rule I'm trying to create that copies files
uses the destination file as the target, so I'm using the target name in
the OUTPUT section of add_custom_command.  Basically, my current
implementation is like this:

  function(stageobj target dir)
  get_property(targetpath TARGET ${target} PROPERTY LOCATION)
  get_filename_component(targetname ${targetpath} NAME)
  add_custom_command(OUTPUT ${DESTDIR}/${dir}/${targetname}
  COMMAND ${CMAKE_COMMAND} -E make_directory ${DESTDIR}/${dir}
  COMMAND ${CMAKE_COMMAND} -E copy ${targetpath} ${DESTDIR}/${dir}
  DEPENDS ${target}
  COMMENT Staging ${target} to ${DESTDIR}/${dir}
  VERBATIM)

  add_custom_target(stage_${target} ALL DEPENDS 
${DESTDIR}/${dir}/${target})
  endfunction()

This has the very nice feature that it's a real rule, and it only fires
if needed (that is, ${target} has been updated since the last time we
copied it).

But, I can't replace ${targetname} in the OUTPUT section with a
generator expression, because they don't seem to be allowed there:

  CMake Error at CMake/Stage.cmake:93 (add_custom_command):
add_custom_command called with OUTPUT containing a .  This character is
not allowed.

Thoughts or alternatives are welcome...

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] Help with Policy CMP0026 (disallow LOCATION target property)

[Paul Smith]

On Tue, 2014-12-23 at 21:32 +, Parag Chandra wrote:
 Have you tried the CMake variables LIBRARY_OUTPUT_PATH and
 EXECUTABLE_OUTPUT_PATH? I¹ve been using them to accomplish much the
 same thing.

Well, I don't want ALL my executables and libraries to go into these
locations.  Only specific ones.  However, I see that there's a target
property RUNTIME_OUTPUT_DIRECTORY, etc. so maybe setting that property
would be an option.

When I first started messing with this cmake environment we had a batch
of scripts, etc. that were using the original location so I really
needed things to live in both locations, for backward compatibility.
But at this point I'm pretty sure no one uses the original locations
anymore so this could work.  I'll look into it.

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

[CMake] Help with Policy CMP0026 (disallow LOCATION target property)

[Paul Smith]

Hi all.  I need a pointer or two.

In my environment I need to have my executables and binaries copied to
another location; this has to happen as part of the default all
target: it can't be required to run install for example (we use the
install rule for a real install step, for one thing).

What I was doing with 2.8.12 was creating a custom target stage_foo
with a prerequisite of target foo, which had a custom command that
copied foo.  To do this I need to run get_property(pth TARGET foo
PROPERTY LOCATION) so I know where the target file is living, and then I
use cmake -E copy ${pth} ${DESTDIR} to copy it to the right place.

In 3.x this use is deprecated and I wonder what to do instead.

If I add a POST_BUILD custom command directly to target foo which
copies the file then I can use $TARGET_FILE:foo in my COMMAND script
and that works...

Except, if someone deletes the copy of the file without touching
anything else, it doesn't get recopied (because cmake doesn't know about
the copy and so doesn't realize something is wrong).

I need this to be recopied because we have a habit of just deleting the
entire destination directory and re-running the build to make a fresh
copy without changing anything else.

I've thought about many ways to do this, but I can't seem to get around
the fact that generator expressions like $TARGET_FILE... are only
available within the commands of the target.

Help?
Thx!

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [cmake-developers] [CMake] Forcing colorization of output from cmake

[Paul Smith]

Thanks Brad.  I wrote a bunch more below and left it for posterity.
However thinking more about this I wonder if we couldn't make this
simpler.

What I really want is that if MAKE_TERMOUT is set to a non-empty value,
cmake should pretend that it's in a terminal regardless of what isatty()
says.  We can do this easily enough by adding a simple test to
Terminal.c:kwsysTerminalStreamIsVT100() _without_ adding any code
anywhere else:

   /* Check for a valid terminal.  */
   if(!default_vt100)
 {
 ...
 }
+
+  /* If we're being run from GNU make 4.1+ see if IT thinks we have a TTY.  */
+  const char* termout = getenv(MAKE_TERMOUT);
+  if(termout  termout[0] != '\0')
+{
+return 1;
+}

In a way this is gross, certainly, but this function already checks for
environment variable such as TERM, EMACS, etc. which are set by calling
utilities and handles them specially.  So why not MAKE_TERMOUT as well?

That one change is enough for my particular use-case, without any other
changes (don't need a FORCE setting for color).  I think it would be
useful to allow FORCE (I think this is a good capability to provide; as
I mentioned other tools that support colorization such as GCC etc. to
provide an always-type flag) but it would be decoupled from this GNU
make capability.

Thoughts?


On Thu, 2014-10-09 at 09:55 -0400, Brad King wrote:
 The Source/kwsys part of the change actually belongs in a separate
 KWSys upstream first.  I've added a modified version of your change
 for upstream review and testing here:
 
  http://review.source.kitware.com/17578
 
 Please try out that version with the rest of your changes.

OK.  I see that in your version FORCE only comes into effect if we have
a known good terminal (the new code comes after the check for valid
terminal).

Personally I would expect FORCE to be stronger than that, and return
true regardless of TERM settings.  Whether or not it should override
EMACS env.var. I don't know... I'm on the fence.  In my solution I had
it really FORCE; that is, kwsysTerminalStreamIsVT100() effectively
always was true if --switch=FORCE, regardless of EMACS or TERM.

I'm not at all familiar with Windows so I have no strong opinions on
whether FORCE should also force color output on a Windows console...
although I know a number of people who do use GNU make on Windows and
the Windows port of GNU make does set MAKE_TERMOUT properly.

  it's darn handy to have this just work without having to export
  COLOR='$(if $(MAKE_TERMOUT),FORCE)' in your ~/.bashrc or whatever.
  There's no GNU Makefiles generator, and I couldn't come up with a good
  way to implement this in the generic Unix Makefiles generator.
 
 We already have a CMAKE_COLOR_MAKEFILE option.  Perhaps instead
 of just ON or OFF values it could have a GNU value that enables
 this behavior.  When initializing it in CMakeGenericSystem.cmake
 perhaps it is possible to detect if CMAKE_MAKE_PROGRAM is a GNU
 make tool and provide a good default.

Well, it's easy enough to detect if CMAKE_MAKE_PROGRAM is GNU make, if
we can run it to test the output of ${CMAKE_MAKE_PROGRAM} --version.

The question is, what do you do in the generated makefile if you see
that it's GNU make?  Anything you'd generate into the makefile that
could choose to set --switch=FORCE would have to be GNU-specific (I
can't think of a way to write it using POSIX standard makefile syntax).
It would need to be the equivalent of:

   --switch=$(or $(COLOR),$(if $(MAKE_TERMOUT),FORCE))

to preserve the current behavior, where the COLOR variable setting can
be inherited from the environment.

What if someone runs cmake and it detects GNU make, but then they run
/my/other/make which is not GNU make?  That would work fine now but
fail if we generated GNU-specific content in 'Unix Makefiles'
generators.

If we had a different generator, like 'GNU Makefiles' for example, then
people who chose that would clearly expect the results would only work
with GNU make, but we don't have that.

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] [CMake] Forcing colorization of output from cmake

[Paul Smith]

On Wed, 2014-10-08 at 12:55 -0400, Brad King wrote:
 On 10/08/2014 12:15 PM, Paul Smith wrote:
  Maybe we could add another valid value to --switch, like --switch=FORCE
  which would always colorize.
 [snip]
  The best option seems to be to add another flag to the color bitflag
  variable that forces colorization always.
 
 Yes, I think both of the above make sense.  If you want to work on
 it please read CONTRIBUTING.rst from the top of our source tree
 in Git ( http://cmake.org/cmake.git ) and come to the developers
 list with a proposal:

Hi all.  Attached please find a proposed patch for the above.  I still
think there's some slightly awkward redundancy between AssumeTTY and the
new ForceTTY, but I'm not sure these can actually be combined into one
flag... certainly not without reworking more of how AssumeTTY is
interpreted and used than I felt confident with.

I didn't try to allow FORCE to be case-insensitive.  It wouldn't be
hard, but I wasn't sure if it was worth it.  You must capitalize it as
the code is written today.  I found precedent for both options.

Also, the check for MAKE_TERMOUT might not be something you want to
keep... there's not a lot of precedent in the code, that I found, for
looking at other utilities' environment variables.  On the other hand
it's darn handy to have this just work without having to export
COLOR='$(if $(MAKE_TERMOUT),FORCE)' in your ~/.bashrc or whatever.
There's no GNU Makefiles generator, and I couldn't come up with a good
way to implement this in the generic Unix Makefiles generator.
From 82d2c63750c706e5f4f749a123934c725432 Mon Sep 17 00:00:00 2001
From: Paul Smith p...@mad-scientist.net
Date: Wed, 8 Oct 2014 14:18:14 -0400
Subject: [PATCH] cmake: Allow forced color output

Provide a new Terminal.h flag, Color_ForceTTY, which causes color output
always regardless of TTY/Console settings.  If --switch=FORCE is given
on the cmake command line, enable this flag.  Also check for the
MAKE_TERMOUT variable, set by GNU make 4.1+ when make is capturing
stdout which will eventually go to a terminal, and set Color_ForceTTY.
---
 Source/cmSystemTools.cxx   | 36 +---
 Source/cmcmd.cxx   |  8 +++-
 Source/kwsys/Terminal.c|  8 +---
 Source/kwsys/Terminal.h.in | 17 +++--
 4 files changed, 48 insertions(+), 21 deletions(-)

diff --git a/Source/cmSystemTools.cxx b/Source/cmSystemTools.cxx
index fbb4416..7c983c6 100644
--- a/Source/cmSystemTools.cxx
+++ b/Source/cmSystemTools.cxx
@@ -2290,31 +2290,45 @@ std::string const cmSystemTools::GetCMakeRoot()
 void cmSystemTools::MakefileColorEcho(int color, const char* message,
   bool newline, bool enabled)
 {
+  if(!enabled)
+{
+// Color is disabled.  Print without color.
+fprintf(stdout, %s%s, message, newline? \n : );
+return;
+}
+
   // On some platforms (an MSYS prompt) cmsysTerminal may not be able
   // to determine whether the stream is displayed on a tty.  In this
   // case it assumes no unless we tell it otherwise.  Since we want
   // color messages to be displayed for users we will assume yes.
   // However, we can test for some situations when the answer is most
-  // likely no.
-  int assumeTTY = cmsysTerminal_Color_AssumeTTY;
+  // likely no, and other cases where it should be forced to yes.
+  int flags = cmsysTerminal_Color_AssumeTTY;
+
   if(cmSystemTools::GetEnv(DART_TEST_FROM_DART) ||
  cmSystemTools::GetEnv(DASHBOARD_TEST_FROM_CTEST) ||
  cmSystemTools::GetEnv(CTEST_INTERACTIVE_DEBUG_MODE))
 {
 // Avoid printing color escapes during dashboard builds.
-assumeTTY = 0;
-}
-
-  if(enabled)
-{
-cmsysTerminal_cfprintf(color | assumeTTY, stdout, %s%s,
-   message, newline? \n : );
+flags = 0;
 }
   else
 {
-// Color is disabled.  Print without color.
-fprintf(stdout, %s%s, message, newline? \n : );
+// Newer versions of GNU make (4.0+) have the ability to separate the
+// output of parallel builds so they don't interfere with each other.
+// However this means commands invoked by make don't appear to have a TTY.
+// GNU make 4.1+ exports an environment variable MAKE_TERMOUT which is
+// non-empty if make thinks that it is printing _it's_ output to stdout.
+// If this variable exists and is non-empty, then force color output.
+const char* var = cmSystemTools::GetEnv(MAKE_TERMOUT);
+if(var  var[0] != '\0')
+  {
+  flags |= cmsysTerminal_Color_ForceTTY;
+  }
 }
+
+  cmsysTerminal_cfprintf(color | flags, stdout, %s%s,
+ message, newline? \n : );
 }
 #endif
 
diff --git a/Source/cmcmd.cxx b/Source/cmcmd.cxx
index a0c67e0..af9b139 100644
--- a/Source/cmcmd.cxx
+++ b/Source/cmcmd.cxx
@@ -907,6 +907,7 @@ int cmcmd::ExecuteEchoColor(std::vectorstd::string args)
 
   bool enabled = true;
   int color = cmsysTerminal_Color_Normal;
+  int force = 0;
   bool

Re: [CMake] Generator-independent incremental CMake run

[Paul Smith]

On Wed, 2014-08-13 at 21:40 +0200, Nagger wrote:
 Does anyone already came up with a good solution? Isn't this a common 
 problem?

I'm not sure about the other generators, but the makefile generator has
this built-in; that is, if the makefiles detect that a cmake file has
changed it will re-run cmake then restart the build.


-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] Critical Xcode problem with OBJECT libraries

[Paul Smith]

I've built CMake 3.0.0-rc1 and tested it, and I still see this same bug
with that version of CMake.

Anyone have any ideas?  Not having reliable builds is wreaking total
havoc on the Xcode users on our development team.


On Wed, 2014-02-19 at 15:17 -0500, Paul Smith wrote:
 Hi all.  I'm using CMake 2.8.12.1 on Linux, MacOSX, and Windows.
 
 On my system I need to build libraries in a large number of
 subdirectories and link them (statically) with various executables
 (different executables use different libraries).  Then I also need to
 take the content of all those libraries and include them into a single
 shared library / DLL.  I understand this is tricky for CMake and so the
 special OBJECT library type was introduced to help with that.
 
 Here's a repro case for the problem I see:
 
   cmake_minimum_required(VERSION 2.8.12)
   project(CMTEST CXX)
 
   add_library(foo_OBJECTS OBJECT foo.cpp foo.h)
 
   add_library(foo STATIC dummy.cpp $TARGET_OBJECTS:foo_OBJECTS)
   add_dependencies(foo foo_OBJECTS)
 
   add_executable(hello hello.cpp)
   target_link_libraries(hello foo)
 
 I needed to add the dummy.cpp because I previously learned that Xcode
 can't handle creating a library only from OBJECTS like this.  It
 contains nothing but a comment.
 
   * I run cmake -G Xcode
   * I run xcodebuild build -config RelWithDebInfo
   * Everything is built correctly
   * Now I modify foo.cpp
   * I run xcodebuild build -config RelWithDebInfo
 
 For the last step I expect that:
  1. foo.cpp will be recompiled
  2. libfoo.a library will be updated
  3. the hello program will be rebuilt.
 
 As a side-effect I guess a hidden libfoo_OBJECTS.a will be created,
 but I don't actually care about that.
 
 This is how it works with Makefile and MSVC.  With Xcode, though, what
 actually happens is that the libfoo_OBJECTS.a is rebuild, BUT it does
 NOT rebuild libfoo.a and it does NOT relink the hello executable!!
 
 I've explicitly stated a dependency between the foo library target and
 the foo_OBJECTS target, and it still does not rebuild on changes!
 
 As you can imagine this is causing my Xcode-based builds to be
 completely unreliable: they fail with weird link errors, or else at
 runtime with strange vtable issues.
 
 Anyone else able to reproduce this?  Is it a known limitation of Xcode?
 Any ideas for workarounds?
 


-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Help debug crazy Windows MSVC issue

[Paul Smith]

On Mon, 2014-02-17 at 08:34 -0500, Paul Smith wrote:
 On Mon, 2014-02-17 at 10:20 +0100, Hendrk Sattler wrote:
  Visual Studio 10 totally relies on the custom build tool to protect 
  itself when run in parallel.  It will run the generator as many times
  as the bar.cpp is mentioned in different targets, even in parallel if
  that is enabled.
 
 Yes, this matches what I found after sending my last email.

 The problem, of course, is that it uses the exact same .OBJ file to
 link into both the shared and static libraries.  In my real
 environment I'm using different -D* flags, so that doesn't work.

Thanks to all that helped.  I eventually solved this problem by
deciding I didn't need this code linked into my static libraries, so I
didn't need to compile the code twice with different flags.

MSVC seems to be stable now... this is a bummer though.

It might be helpful to add this limitation to the docs or a FAQ or
something, for posterity.

Unfortunately I've now run into a problem with Xcode generation which is
at least as concerning.  I'll start a new thread.

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] Critical Xcode problem with OBJECT libraries

[Paul Smith]

Hi all.  I'm using CMake 2.8.12.1 on Linux, MacOSX, and Windows.

On my system I need to build libraries in a large number of
subdirectories and link them (statically) with various executables
(different executables use different libraries).  Then I also need to
take the content of all those libraries and include them into a single
shared library / DLL.  I understand this is tricky for CMake and so the
special OBJECT library type was introduced to help with that.

Here's a repro case for the problem I see:

  cmake_minimum_required(VERSION 2.8.12)
  project(CMTEST CXX)

  add_library(foo_OBJECTS OBJECT foo.cpp foo.h)

  add_library(foo STATIC dummy.cpp $TARGET_OBJECTS:foo_OBJECTS)
  add_dependencies(foo foo_OBJECTS)

  add_executable(hello hello.cpp)
  target_link_libraries(hello foo)

I needed to add the dummy.cpp because I previously learned that Xcode
can't handle creating a library only from OBJECTS like this.  It
contains nothing but a comment.

  * I run cmake -G Xcode
  * I run xcodebuild build -config RelWithDebInfo
  * Everything is built correctly
  * Now I modify foo.cpp
  * I run xcodebuild build -config RelWithDebInfo

For the last step I expect that:
 1. foo.cpp will be recompiled
 2. libfoo.a library will be updated
 3. the hello program will be rebuilt.

As a side-effect I guess a hidden libfoo_OBJECTS.a will be created,
but I don't actually care about that.

This is how it works with Makefile and MSVC.  With Xcode, though, what
actually happens is that the libfoo_OBJECTS.a is rebuild, BUT it does
NOT rebuild libfoo.a and it does NOT relink the hello executable!!

I've explicitly stated a dependency between the foo library target and
the foo_OBJECTS target, and it still does not rebuild on changes!

As you can imagine this is causing my Xcode-based builds to be
completely unreliable: they fail with weird link errors, or else at
runtime with strange vtable issues.

Anyone else able to reproduce this?  Is it a known limitation of Xcode?
Any ideas for workarounds?

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Help debug crazy Windows MSVC issue

[Paul Smith]

Thanks Hendrk.  It's good to know I'm not crazy or overlooking something
simple, even if the answer is not what I wanted.

I did some other experimentation last night and I'll followup with some
results, which may be interesting.

Can anyone tell me how to get the Visual Studio output to show complete
command lines, including switches, for the compiler and linker?  The
equivalent to make VERBOSE=1?  All the searching I've done suggests
starting Visual Studio and invoking the build from there after tweaking
some configuration, but I'm running via a remote terminal and using
devenv to start the build.  Is there no way to do this without building
from inside VS?


On Mon, 2014-02-17 at 10:20 +0100, Hendrk Sattler wrote:
 The DEPENDS above should be a MAIN_DEPENDENCY (not sure if that
 actually changes anything)

Unfortunately in my real situation, a single invocation of the generator
actually builds 43 different source and header files, and its input is a
similar (but not one-for-one) number of files.  So there's no obvious
MAIN_DEPENDENCY.  I don't think it matters, based on my reading of the
cmake docs.

My situation is even more complicated because the generator itself is a
Java program that needs to be built, by cmake, before it can be invoked
to generate the files.

 The custom target gains you nothing. The problem here are actually the
 tools: Visual Studio 10 totally relies on the custom build tool to
 protect itself when run in parallel.

Just to be clear, VS 2012 would behave the same way right?  We have had
on our project plans migrating there; if it might fix this problem we
could re-evaluate priorities.  But I expect that wouldn't matter.

 It will run the generator as many times as the bar.cpp is mentioned in
 different targets, even in parallel if that is enabled. And that's
 what you see.

That's a critical bit of information, and does indeed jibe with what I'm
seeing and what I discovered after I sent my last email.  I'll follow up
with some notes.

 Solutions:
 a) Add cmake -E copy_if_different to bar-static.cpp and
 bar-shared.cpp and use those (means: use generated leaf files only in
 one target).
 or
 b) Switch off the parallel (target) building in the Visual Studio 
 options (this will still generate the files multiple times)
 or
 c) Use jom (and NMake Makefiles generator)

If it were up to me I'd switch to using UNIX Makefiles and install GNU
make on the Windows systems, just because it's a known quantity (that
seems to work).  Unfortunately there are a few people who use Visual
Studio as development environments and they certainly want CMake to
generate the project files for them.

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Help debug crazy Windows MSVC issue

[Paul Smith]

On Mon, 2014-02-17 at 10:20 +0100, Hendrk Sattler wrote:
 Visual Studio 10 totally relies on the custom build tool to protect 
 itself when run in parallel.  It will run the generator as many times
 as the bar.cpp is mentioned in different targets, even in parallel if
 that is enabled.

Yes, this matches what I found after sending my last email.  I was able
to get something to work the way I wanted, following the outline I had
originally provided using an OBJECT library instead of using source
files directly, like this (I made the generator more complex to better
emulate my real environment):

  cmake_minimum_required(VERSION 2.8.12)

  project(TEST C CXX)

  include_directories(${CMAKE_CURRENT_BINARY_DIR})

  add_custom_command(OUTPUT bar.cpp bar.h biz.cpp biz.h
  COMMAND sh ${CMAKE_CURRENT_SOURCE_DIR}/genfile bar bar biz
  COMMAND sh ${CMAKE_CURRENT_SOURCE_DIR}/genfile biz bar biz
  DEPENDS foo.cpp ${CMAKE_CURRENT_SOURCE_DIR}/genfile
  COMMENT GENERATING bar.cpp)

  set_source_files_properties(bar.cpp bar.h biz.cpp biz.h
  PROPERTIES GENERATED TRUE)

  add_library(Bobj OBJECT bar.cpp bar.h biz.cpp biz.h)

  add_library(Bar STATIC base.cpp $TARGET_OBJECTS:Bobj)
  add_library(BarDLL SHARED base.cpp $TARGET_OBJECTS:Bobj)

By creating the Bobj OBJECT library I'm only mentioning the source
file one time and this appears to make things work properly: the
generator is only invoked one time, and if I re-run the build without
changing anything, nothing is rebuilt.


The problem, of course, is that it uses the exact same .OBJ file to link
into both the shared and static libraries.  In my real environment I'm
using different -D* flags, so that doesn't work.

Also I'm not as familiar with Windows; do you need to compile the OBJ
files differently if you're targeting static vs. DLL libraries (similar
to UNIX's -fPIC flag--although -fPIC can actually be specified for both
static and shared libraries)?

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] Help debug crazy Windows MSVC issue

[Paul Smith]

I'm using CMake 2.8.12.1 on Linux, MacOS, and Windows.  On Windows I'm
using MSVC 2010 and the Visual Studio generator, but I have only remote
access so I'm invoking my builds using devenv (not running Visual
Studio).

I'm deeply involved in some messy hackery related to building the same
code as a static library and as a DLL, and ensuring that the export and
import decorations are correct etc.  This is further complicated by the
fact that some of the source files are themselves generated.

This is all working great on Linux (Makefile generator) and MacOS (Xcode
and Makefile generators).  But it's completely unreliable on Windows
(Visual Studio generator).

What happens on Windows is that the generator runs TWICE, not once, and
in preparation for running the second time it deletes all the output
from the first run, and so if some other part of the build is trying to
compile and access some of the generated code at that time, the build
fails.  If it happens that no other part of the build needs to access
the generated content while the second run is generating it, then the
build succeeds.

I need some help or pointers or tips in how to figure out the problem;
I'm really not a Windows person.

What I've got is something like this:

  set(GENERATED ..list of generated .cpp and .h files..)

  set_source_files_properties(${GENERATED} PROPERTIES GENERATED TRUE)

  add_custom_command(OUTPUT ${GENERATED}
  COMMAND ...
  DEPENDS ...
  COMMENT Generating output)

  add_library(Generated OBJECT ${GENERATED})

  add_library(BaseShared_OBJECTS OBJECT file1.cpp file2.cpp ...)
  add_library(BaseShared SHARED dummy.cpp $TARGET_OBJECTS:Generated 
$TARGET_OBJECTS:BaseShared_OBJECTS)
  add_dependencies(BaseShared BaseShared_OBJECTS)

  add_library(BaseStatic_OBJECTS OBJECT file1.cpp file2.cpp ...)
  add_library(BaseStatic STATIC dummy.cpp $TARGET_OBJECTS:Generated 
$TARGET_OBJECTS:BaseShared_OBJECTS)
  add_dependencies(BaseShared BaseShared_OBJECTS)

I originally just had the two libraries contain the ${GENERATED} source
directly, but had this duplicate build issue so I tried to create an
OBJECT library and have that library as the prerequisite.  However it
still seems to happen.

The reason I need to use the OBJECT libraries for BaseShared and
BaseStatic is that I need to link these into other shared libraries as
well.

Anyway, I can see in my build output the first Generating output, and
the output is generated and all is compiling along nicely... then later
on I see ANOTHER Generating output and all heck breaks loose.


I just can't figure out what's going on and I don't know how to work
with/debug Visual Studio project files (if this was a makefile generator
I'd just read the makefile).

Some concrete questions (please remember I'm running devenv via a
terminal: I don't have ready access to Visual Studio):

(A) Can I force the build to run serially?  Or is there some way I can
more easily see what forces the second generator to run?

(B) Can I get the command lines for the compiler and linker, etc. to be
shown?  I tried setting CMAKE_VERBOSE_MAKEFILE but that didn't help.

(C) Any other ideas about what I can do to make this simpler and more
reliable?

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Help debug crazy Windows MSVC issue

[Paul Smith]

On Sun, 2014-02-16 at 21:35 -0500, Paul Smith wrote:
 I'm using CMake 2.8.12.1 on Linux, MacOS, and Windows.  On Windows I'm
 using MSVC 2010 and the Visual Studio generator, but I have only
 remote access so I'm invoking my builds using devenv (not running
 Visual Studio).

Here's a simplified repro case (this is run from a Git shell, just
because I can't manage command.com; but I've run it from there with
identical results):

  $ cd cmtest

  $ cat CMakeFiles.txt
  cmake_minimum_required(VERSION 2.8.12)

  project(TEST C CXX)

  add_custom_command(OUTPUT bar.cpp
  COMMAND cmake -E copy ${CMAKE_CURRENT_SOURCE_DIR}/foo.cpp bar.cpp
  DEPENDS foo.cpp
  COMMENT Creating bar.cpp)

  add_library(Bar STATIC base.cpp bar.cpp)

  add_library(BarDLL SHARED base.cpp bar.cpp)

  $ cat base.cpp
  int base = 0;
  int restbase()
  {
  return base;
  }

  $ cat foo.cpp
  int foo = 0;
  int restfoo()
  {
  return foo;
  }

For simplicity of cleaning I'll use a remote directory build:

  $ mkdir ../cmobj

  $ cd ../cmobj

  $ cmake ../cmtest

  $ cmake --build .

Now in the results you'll see that the Creating bar.cpp is printed
twice, showing that the custom command is run twice.

This doesn't happen for makefiles.

How can I structure my cmake file to avoid this double build?

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Help debug crazy Windows MSVC issue

[Paul Smith]

On Sun, 2014-02-16 at 22:38 -0500, David Cole wrote:
  How can I structure my cmake file to avoid
  this double build?
 
 
 Put the custom command in a custom target, and make the libraries using 
 the generated file depend on the custom target.
 
 That works, even for parallel builds.
 
 Google around for examples and similar advice. You'll end up using 
 add_custom_target and add_dependencies in addition to what you already 
 have.

I was thinking about that earlier, but I didn't do it because the docs
for add_custom_target() say:

  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.

To me this means that every time I run the build, even if nothing has
changed, the files will be regenerated and all the targets that depend
on the files will be recompiled and everything will be relinked.  Am I
misreading it?  That's a pretty significant hit to performance and
productivity, if I understand it properly.

I'll play with it in my test setup and see how it goes.

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Help debug crazy Windows MSVC issue

[Paul Smith]

On Mon, 2014-02-17 at 00:20 -0500, Paul Smith wrote:
 On Sun, 2014-02-16 at 22:38 -0500, David Cole wrote:
   How can I structure my cmake file to avoid
   this double build?
  
  Put the custom command in a custom target, and make the libraries using 
  the generated file depend on the custom target.
  
  That works, even for parallel builds.
  
  Google around for examples and similar advice. You'll end up using 
  add_custom_target and add_dependencies in addition to what you already 
  have.
 
 I was thinking about that earlier, but I didn't do it because the docs
 for add_custom_target() say:
 
   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.

Thanks for the reply, but this isn't working.

First, unlike most of the examples I've found I'm generating C++ source
code, and if I leave the output of the custom command as the generated
source then I ALWAYS get the double build.  In fact if I put
add_custom_target it builds THREE times; I tried this:

  cmake_minimum_required(VERSION 2.8.12)

  project(TEST C CXX)

  add_custom_command(OUTPUT bar.cpp
  COMMAND cmake -E copy ${CMAKE_CURRENT_SOURCE_DIR}/foo.cpp bar.cpp
  DEPENDS foo.cpp
  COMMENT GENERATING bar.cpp)

  set_source_files_properties(bar.cpp PROPERTIES GENERATED TRUE)

  add_custom_target(BuildBar DEPENDS bar.cpp)

  add_library(Bar STATIC base.cpp bar.cpp)
  add_library(BarDLL SHARED base.cpp bar.cpp)

  add_dependencies(Bar BuildBar)
  add_dependencies(BarDLL BuildBar)

and this caused the GENERATING bar.cpp line to be run three times
during my build (setting or not setting the GENERATED property doesn't
appear to make any difference here).

So then I tried to use a separate OUTPUT name for the custom command
which was not the source file.  This time I only get one GENERATING line
so it's only run one time, BUT every time I run the build it regenerates
that source file and hence recompiles and relinks both libraries:

  cmake_minimum_required(VERSION 2.8.12)

  project(TEST C CXX)

  add_custom_command(OUTPUT bldbar
  COMMAND cmake -E copy ${CMAKE_CURRENT_SOURCE_DIR}/foo.cpp bar.cpp
  DEPENDS foo.cpp
  COMMENT GENERATING bar.cpp)

  set_source_files_properties(bar.cpp PROPERTIES GENERATED TRUE)

  add_custom_target(BuildBar DEPENDS bldbar)

  add_library(Bar STATIC base.cpp bar.cpp)
  add_library(BarDLL SHARED base.cpp bar.cpp)

  add_dependencies(Bar BuildBar)
  add_dependencies(BarDLL BuildBar)

Neither of these is what I need.

Is there an option which gives me reliable builds, but doesn't force the
majority of my codebase to be rebuilt every time even if nothing
changes?


-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] AStyle or similar code beautifier

[Paul Smith]

On Fri, 2014-01-31 at 02:26 -0800, Alan W. Irwin wrote:
 And to answer the OP's question, I can highly recommend uncrustify for
 code styling

I agree with Alan.  We did a huge reformatting effort last year to
change a very large C++ codebase from a style based loosely on
Whitesmith to a more common style.  I started with AStyle which is a
solid program, but it has limited customization support.

Then I found uncrustify and was quite satisfied with it.  I sent a few
patches for minor fixes and they were well received.  The main issue
with uncrustify is that the documentation could be better: for some of
the more advanced settings it's very hard to understand exactly what
they control.

I had to do a bit of scripting around it since uncrustify didn't handle
all the whitespace conversion we wanted, but it worked great!

We didn't try to integrate it with the build system.  We just checked in
the configuration file and a script people could use if they wanted to
re-beautify their code.

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] AStyle or similar code beautifier

[Paul Smith]

On Fri, 2014-01-31 at 14:24 +0100, Eric Noulard wrote:
  We didn't try to integrate it with the build system.  We just checked in
  the configuration file and a script people could use if they wanted to
  re-beautify their code.
 
 Would you mind sharing the script you used with us?

Sure, it's pretty simple.  Works on Linux and Mac.  Windows users have
to fend for themselves :-).

In addition to standard uncrustify, this converts all TABs to the
appropriate number of spaces (uncrustify doesn't mess with stuff inside
comments for example) and it removes all trialing whitespace.

This doesn't make any backup files; it's assumed you're using a source
control system and you've committed a copy beforehand (because it was
written for a one-time reformat originally) but if you want to keep
the .orig file for safety, just don't delete it.



reformat.sh
Description: application/shellscript
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] [2.8.12.1] Bug in Xcode generation of STATIC from OBJECT libraries

[Paul Smith]

Hi all.  I'm using CMake 2.8.12.1 on Linux, MacOS, and Windows.  I've
discovered a bug in the Xcode generator when dealing with OBJECT and
STATIC libraries.  This example works fine on Linux, and on MacOS with
the Makefile generator.  I also haven't noticed a problem on Windows
(MSVC).

What I'm doing is creating an OBJECT library then creating a STATIC
library from that (and I'm also creating a SHARED library from the same
OBJECT library, but that's not relevant to this bug).

Here's the test file:

  cmake_minimum_required(VERSION 2.8.12)
  project(TestLib C)

  add_library(mylib_OBJECTS OBJECT mylib.c)
  add_library(mylib STATIC $TARGET_OBJECTS:mylib_OBJECTS)

  add_executable(libtest libtest.c)
  target_link_libraries(libtest mylib)

I have trivial mylib.c and libtest.c files.

The Makefile generators work fine; the libmylib.a library is created and
linked to libtest just as you'd expect.

For Xcode, though, the link fails:

  Ld Debug/libtest normal x86_64
  cd /Users/build/xcode-bug
  /Developer/usr/bin/llvm-gcc-4.2 -arch x86_64 -isysroot 
/Developer/SDKs/MacOSX10.7.sdk -L/Users/build/xcode-bug/Debug 
-F/Users/build/xcode-bug/Debug -filelist 
/Users/build/xcode-bug/TestLib.build/Debug/libtest.build/Objects-normal/x86_64/libtest.LinkFileList
 -mmacosx-version-min=10.7 -Wl,-search_paths_first 
-Wl,-headerpad_max_install_names /Users/build/xcode-bug/Debug/libmylib.a -o 
/Users/build/xcode-bug/Debug/libtest
  Command /Developer/usr/bin/llvm-gcc-4.2 failed with exit code 1

The reason this fails is that while the link line is correctly trying to
link the Debug/libmylib.a library, the library that Xcode actually built
is quite different:

  $ find . -name libmylib\*
  ./TestLib.build/Debug/mylib_OBJECTS.build/Objects-normal/libmylib_OBJECTS.a

This is not right.

Cheers!

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] [2.8.12.1] Bug in Xcode generation of STATIC from OBJECT libraries

[Paul Smith]

On Thu, 2014-01-23 at 10:22 -0500, Brad King wrote:
 On Thu, Jan 23, 2014 at 8:03 AM, Paul Smith p...@mad-scientist.net wrote:
add_library(mylib STATIC $TARGET_OBJECTS:mylib_OBJECTS)
 [snip]
  The Makefile generators work fine
 
  For Xcode, though, the link fails:
 
 This is a known limitation.  From the add_library documentation:
 
  http://www.cmake.org/cmake/help/v2.8.12/cmake.html#command:add_library
  Some native build systems may not like targets that have only object files,
   so consider adding at least one real source file

I see.  That's a shame :-(.

I have lots of these libraries and so I was trying to write a macro that
would do all this stuff for me (create the OBJECT library then the
STATIC library, plus it does a few other things I need done like set
certain properties).

Then later in one CMakeLists.txt file I would collect all the OBJECT
libraries into a single SHARED library, like:

  set(SO_OBJECTS)
  foreach(LIB lib1 lib2 lib3 lib4)
  list(APPEND SO_OBJECTS $TARGET_OBJECTS:${LIB}_OBJECTS)
  endforeach()

That worked great--for makefile generators.

If I have to exclude one of the source files from the OBJECT library so
I can include it directly into the STATIC library, now somehow I have to
also remember that extra source file so it can be included in the SHARED
library as well.

Also, doesn't that mean that I'll be compiling those source files which
are omitted from the OBJECT library twice, once for shared and once for
static?

Kind of unpleasant.  Anyone have any ideas?

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] [2.8.12.1] Bug in Xcode generation of STATIC from OBJECT libraries

[Paul Smith]

On Thu, 2014-01-23 at 11:40 -0500, Brad King wrote:
 On 01/23/2014 11:36 AM, Paul Smith wrote:
  I see.  That's a shame :-(.
 
 Unfortunately it is an Xcode limitation that CMake cannot work around.
 
  Kind of unpleasant.  Anyone have any ideas?
 
 Add an empty.c source protected by if(XCODE).

Yeah, I thought about that.  Tested it here and it worked.  OK, I can
manage that.  Plus it gives me a handy place to put a snarky comment
about Xcode :-p :-)

 Also be sure to set the POSITION_INDEPENDENT_CODE target property
 on the object libraries to make sure the objects can be used in
 a shared library.

I've been adding -fPIC by hand but this property looks nicer; I'll check
it out.

Thanks Brad!


-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Patch for cmake-mode.el

[Paul Smith]

On Sun, 2013-11-17 at 20:03 +0200, Raphael Kubo da Costa wrote:
 Roy Crihfield rscr...@gmail.com writes:
 
  I have a patch the the CMake emacs mode I'd like to have reviewed and
  push. What is the preferred way to do this - should I just send the
  patch, or fork and push to the repository?
 
 Both sending a patch to cmake-devel via `git patch' and sending a pull
 request with GitHub should work fine.

I haven't created a patch for it, but the keymap provided with cmake
mode needs to be changed:

  (defvar cmake-mode-map
(let ((map (make-sparse-keymap)))
  (define-key map \C-ch 'cmake-help-command)
  (define-key map \C-cl 'cmake-help-list-commands)
  (define-key map \C-cu 'unscreamify-cmake-buffer)
  map)
Keymap used in cmake-mode buffers.)

This is not good: All keys C-c letter are reserved for users for their
local commands and are not supposed to be mapped by any other modes.

From the Tips section of the Emacs Lisp manual, second bullet:

 Don't define C-c _letter_ as a key in Lisp programs. Sequences
 consisting of C-c and a letter (either upper or lower case) are
 reserved for users; they are the only sequences reserved for users, so
 do not block them.
 Changing all the Emacs major modes to respect this convention was a
 lot of work; abandoning this convention would make that work go to
 waste, and inconvenience users. Please comply with it.

http://www.gnu.org/software/emacs/manual/html_node/elisp/Key-Binding-Conventions.html

Cheers!

--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Patch for cmake-mode.el

[Paul Smith]

On Mon, 2013-11-18 at 00:18 +0200, Raphael Kubo da Costa wrote:
 I'm not sure if this is what Roy originally had in mind; it would be
 good if you could file a bug in CMake's bug tracker for this in any
 case.

I'm sure this isn't what Roy was talking about, I just happened to think
of it when I saw his email regarding cmake-mode.el.

I'll file a bug.

--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Patch for cmake-mode.el

[Paul Smith]

On Sun, 2013-11-17 at 18:19 -0500, Paul Smith wrote:
 On Mon, 2013-11-18 at 00:18 +0200, Raphael Kubo da Costa wrote:
  I'm not sure if this is what Roy originally had in mind; it would be
  good if you could file a bug in CMake's bug tracker for this in any
  case.
 
 I'm sure this isn't what Roy was talking about, I just happened to
 think of it when I saw his email regarding cmake-mode.el.
 
 I'll file a bug.

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

Cheers!

--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Specifying an alternate location for cmake Modules directory

[Paul Smith]

On Thu, 2013-11-14 at 12:41 +0100, Micha Hergarden wrote:
 For the modules you can use cmake_module_path from within your
 scripts.

Unfortunately this doesn't work.  I should have mentioned that I'd
already tried this.  CMake looks for its installation directory as the
very first thing and errors out if it can't be found, long before it
gets around to parsing CMAKE_MODULE_PATH.

Aha.  I've looked at the code and it appears I can do what I want by
setting the environment variable CMAKE_ROOT (not the cmake variable)
before I start cmake.

However, this doesn't really work for me either: the wrappers that set
this variable are not used when cmake is invoked from the makefile, or
whatever, and Failure Ensues.  Attempts to forcibly override
CMAKE_COMMAND, CMAKE_CPACK_COMMAND, and CMAKE_CTEST_COMMAND worked, but
had their own problems.

I did find a way to do what I want though, by rearranging my directories
somewhat:

  tools/linux/bin/cmake   (a wrapper that invokes the real program)
  tools/macosx/bin/cmake  (wrapper)
  tools/windows/bin/cmake.bat (wrapper)

  tools/common/cmake/linux/cmake   (real program)
  tools/common/cmake/macosx/cmake  (real program)
  tools/common/cmake/windows/cmake.exe (real program)
  tools/common/cmake/Modules/...

Ditto for ctest, cpack, etc.

The reason for the wrappers is that I have lots of tools and I want to
add just one directory to $PATH (tools/linux/bin for example) and get
access to all the tools: I don't want to add a different directory for
each tool.  But I need each tool to be installed completely contained in
its own subdirectory.

Done this way I don't need to use CMAKE_ROOT or do anything differently;
it all just works.  Yay!

--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] Specifying an alternate location for cmake Modules directory

[Paul Smith]

I need to maintain my own copy of the latest cmake, and for multiple
different target systems (GNU/Linux, MacOS, Windows, Solaris...)

I have a shared location where all tools like this go, so that
regardless of the system architecture you can access this one location.
Obviously inside that location are architecture-specific areas for
binaries, etc.

There is also a common area for files that can be shared, to reduce disk
usage, copying time, etc.

Since all of the cmake installation with the exception of the binaries
is identical between the different architectures, I want to share all of
the installation (for example the Modules directory, etc.)  I can't use
symlinks.

So what I'd like is a structure something like this:

  .../common/cmake/Modules/...

  .../linux/bin/cmake
  .../darwin/bin/cmake
  .../windows/bin/cmake.exe
  .../sunos/bin/cmake

I can use a wrapper around cmake to set environment variables or pass in
command line flags to the REAL cmake, if necessary.

Is there any way to convince cmake to look in a different place for
Modules etc.?

--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] Can I run a command every time a given target is created?

[Paul Smith]

I need to be able to run a command after a target is created, every time
the target is created.  I need this to happen regardless of the command
line.

For example, for Makefile generators if someone runs make myTarget
directly (if myTarget is a program for example) I still need this
command to be run; similarly for MSVC requesting a particular build
target.

I have my cmake files set up now to use a target created with
add_custom_command() / add_custom_target() with ALL DEPENDS so that if
someone runs plain make or the default MSVC target, then the command
will always be run afterward.  But this doesn't help me when people
build these specific targets.


For example, is it possible to modify the standard build target rule to
add extra commands, in cmake?

--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Fwd: How to have generated source compiled multiple ways?

[Paul Smith]

On Tue, 2013-08-13 at 00:24 +0200, Eric Noulard wrote:
  OK, maybe I'm misunderstanding but if the SerializeTarget is considered
  always out of date because it was defined with add_custom_target()
  then won't that cause the two libraries to always rebuild, since
  something they depend on is always out of date?  Maybe I'm thinking of
  it too much like make.
 
 This is puzzling but as far as I understand it, since SerializeTarget
 has no output it cannot trigger the rebuilt of a target (nioether Lib1
 nor Lib2), however whenever you need (or ask) to build Lib1 or Lib2
 then SerializeTarget has to be executed and consequently the
 add_custom_command will be if the generated.c file is out of date.

OK, I was thinking it was like a .PHONY rule in make, but it looks like
it's rather just like a normal empty rule (if it has no commands).  That
works.  Thanks!

--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] How to have generated source compiled multiple ways?

[Paul Smith]

Hi all.

I've got a situation where I'm creating generated source files (from
bison/flex, actually, but I'm writing my own rules for it since I need
specialized support for C++ output, etc.)

However I need to compile the generated output into two different
libraries, building two different ways (with different #defines/compiler
flags).

So I have tried using add_custom_command() with OUTPUT, but the
documentation says: 


Do not list the output in more than one independent target that
may build in parallel or the two instances of the rule may
conflict (instead use add_custom_target to drive the command and
make the other targets depend on that one).


Sure enough, it seems that if I have my different libraries depend on
these outputs I get problems during parallel builds.  So then I tried to
use add_custom_target(), but that says:


The target has no output file and is ALWAYS CONSIDERED OUT OF
DATE


and, sure enough, if I do it this way my source files (and everything
that depends on them) rebuild every time I run the build, even if
nothing has changed.  This is a big bummer.


How can I have generated source files compiled different ways into
different libraries, but not have them (and anything that depends on
them) rebuilt every time?


The only way I've thought of so far is to have two different
add_custom_command() options with the same input but different output
(in different directories maybe), one for each target.  This means I
need to generate the files twice even though the output source files
will have identical content.  But as long as I don't have to REBUILD
them every time maybe that's not so bad.  I haven't tried this yet
though.  Are there other options?
--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] How to have generated source compiled multiple ways?

[Paul Smith]

On Mon, 2013-08-12 at 22:35 +0200, Eric Noulard wrote:
 2013/8/12 Paul Smith p...@mad-scientist.net:
 
  So I have tried using add_custom_command() with OUTPUT, but the
  documentation says:
 
  Do not list the output in more than one independent target that may build
  in parallel or the two instances of the rule may conflict (instead use
  add_custom_target to drive the command and make the other targets depend on
  that one).
 
  Sure enough, it seems that if I have my different libraries depend on these
  outputs I get problems during parallel builds.  So then I tried to use
  add_custom_target(), but that says:
 
  The target has no output file and is ALWAYS CONSIDERED OUT OF DATE
 
  and, sure enough, if I do it this way my source files (and everything that
  depends on them) rebuild every time I run the build, even if nothing has
  changed.  This is a big bummer.
 
 I did never tried befoire but think you should simply keep your
 current add_custom_command and create a new target with
 add_custom_target whose only purpose is to serialize the dependency
 for the 2 (or more) independent libraries which use the output of your
 custom command concurrently.

 add_custom_target(SerializeTarget
   DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/generated.c)
 
 add_library(MyLib1 ${CMAKE_CURRENT_BINARY_DIR}/generated.c lib1.c)
 set_target_properties(MyLib1 PROPERTIES COMPILE_FLAGS -DDEFGEN=3)
 add_dependencies(MyLib1 SerializeTarget)
 
 add_library(MyLib2 ${CMAKE_CURRENT_BINARY_DIR}/generated.c lib2.c)
 set_target_properties(MyLib2 PROPERTIES COMPILE_FLAGS -DDEFGEN=4)
 add_dependencies(MyLib2 SerializeTarget)

OK, maybe I'm misunderstanding but if the SerializeTarget is considered
always out of date because it was defined with add_custom_target()
then won't that cause the two libraries to always rebuild, since
something they depend on is always out of date?  Maybe I'm thinking of
it too much like make.

I'll look at the stuff you've sent and try to adjust it for my
situation.

Thanks!

--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Xcode generator fails to heed add_custom_command() DEPENDS

[Paul Smith]

On Sun, 2013-07-14 at 19:35 +, David Cole wrote:
   DEPENDS ${targetname}
 
 Instead of using a targetname here in the add_custom_command call, use
 a file name. That’s known to work with the Xcode generator. (I
 think... it’s been a while since I did it personally using Xcode, but
 simple to try...)

Thanks for the note David.  Unfortunately this doesn't help.  It's not
clear what you mean, exactly, by use a file name, but I tried this:

  get_property(myapp_path TARGET myapp PROPERTY LOCATION)

then I used ${myapp_path} in the DEPENDS line instead of
${targetname}, but I got the same failure as before.

From what I can determine about the Xcode generator, it appears to
generate makefile snippets for each target which manage whether that
target should be rebuilt or not.  But it appears that it's the xcodeproj
file that contains the dependency relationships between the individual
targets, and that is not being set up correctly.

After the build fails, I can see that indeed the myapp target has not
been built, even though the pathnames in the makefile are correct.

So, it appears that CMake knows the correct pathname, but it is not
communicating to Xcode that in order to build that pathname it needs to
run a particular target.  Thus, Xcode is not building the targets in the
right order.  Or something like that.

--

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] Running install by default, or alternatives?

[Paul Smith]

On Thu, 2013-05-30 at 08:10 +0200, Petr Kmoch wrote:
 Look up generator expressions in the CMake docs (for example in
 add_custom_command), particularly $CONFIGURATION. It might help in
 solving your issue.

Perfect!  Thanks.


--

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] Fwd: Problems setting CMAKE_CONFIGURATION_TYPES for Visual Studio

[Paul Smith]

This is probably not related, but your comment about deleting the cmake
cache made me think of it: one thing to be sure of is that if you delete
CMakeCache.txt you ALSO delete the CMakeFiles/ directory.

Deleting CMakeCache.txt but not CMakeFiles yields corrupted results
after you run cmake the next time.  Being sure to delete both at the
same time, all the time, allows things to work OK.


On Wed, 2013-05-29 at 16:55 +0200, Petr Kmoch wrote:
 I haven't looked into CMake code deep enough, so I don't really know
 how it works either. Maybe project() stores something into the cache
 which causes it to not trample over the configuration list in the next
 run. Just guessing.
 
 Petr
 
 
 
 On Wed, May 29, 2013 at 4:40 PM, gaga bla gagab...@gmail.com wrote:
 Hello Petr,
 
 i don't understand how this solves the problem, but indeed it
 does!
 
 Still i have one small problem. To make regeneration of a
 clean project as easy as possible, i have a batch file, which
 first clears all generated data (including cmake cache), an
 then runs cmake. Since this fails now the first time, i have
 to run cmake twice in this batch file, but if other errors
 occour, i get output twice.
 
 
 Maybe if i could understand why your solution works, i could
 come up with one that works without running cmake once again?
 
 
 Thanks so far!
 Janosch
 
 
 
 On Wed, May 29, 2013 at 1:34 PM, Petr Kmoch
 petr.km...@gmail.com wrote:
 Hi Janosch.
 
 A solution to this problem which works for me is: if
 the configurations are not those I want, set them
 correctly and abort the generation (with a help
 message).
 
 I put the following code into the CMakeList after the
 call to project():
 
 if(CMAKE_CONFIGURATION_TYPES AND NOT
 CMAKE_CONFIGURATION_TYPES MATCHES FullDebug)
 
   set(cfgs ${CMAKE_CONFIGURATION_TYPES})
 
   list(REMOVE_ITEM cfgs MinSizeRel)
 
   list(APPEND cfg FullDebug)
 
   set(CMAKE_CONFIGURATION_TYPES ${cfgs} CACHE STRING
 List of supported configurations. FORCE)
   message(FATAL_ERROR List of configurations was
 reset, please re-run CMake.)
 endif()
 
 
 
 Hope this helps.
 
 Petr
 
 
 
 On Wed, May 29, 2013 at 1:14 PM, gaga bla
 gagab...@gmail.com wrote:
 
 Hello Eric,
 
 thanks for your reply, i tried this, but in my
 case it doesn't work. I made a function that
 first sets the configuration types (using your
 line of code) and then calls the project
 function. Using this function instead of the
 project function itself, still all
 configurations are beeing generated.
 
 I browsed through the cmake sources and
 modules, but i coudn't find the place that
 reintroduces those configurations.
 
 It looks like a bug to me, later on i will try
 to produce an example.
 
 
 Kind regards
 Janosch
 
 
 
 On Tue, May 28, 2013 at 10:01 PM, Eric Clark
 ecl...@ara.com wrote:
 Our projects limit the types to just
 Debug and Release. However, what I
 found was that you had to set the
 variable before every call to
 project(…). What we did was we created
 a module called BuildTypes.cmake and
 include it first thing in every list
 file. The file has one line of code in
 it that looks like this:
 
  
 
 set(CMAKE_CONFIGURATION_TYPES Debug
 Release CACHE TYPE 

Re: [CMake] Running install by default, or alternatives?

[Paul Smith]

No love for this question apparently :-/

I tried to implement the suggestion in the mailing list post below, and
it works fine with UNIX makefiles.

But, on other generators such as Xcode and MSVC there's a major problem
that I don't know how to solve.  The post suggests forcing a new target
like this:

  add_custom_target(stage_install ALL
  COMMAND ${CMAKE_COMMAND} -P ${CMAKE_BINARY_DIR}/cmake_install.cmake)

which is fine for generators that don't use build types.  However for
generators that do use build types, I don't know how to pass the build
type into the cmake command.

I found that cmake_install.cmake is reading ${BUILD_TYPE}, so I can add
-DBUILD_TYPE=... to the $(CMAKE_COMMAND} in the stage_install target
above if I can figure out what ... should be.

So when I run, for example, xcodebuild build -configuration Debug, how
do I write that custom target command so it can find the configuration
name Debug that xcodebuild was invoked with?


Basically all I can do now is hardcode the build type at cmake time, so
if you want to use a different build type you must re-run cmake with a
different -DCMAKE_BUILD_TYPE= flag :-/.



On Fri, 2013-05-24 at 11:41 -0400, Paul Smith wrote:
 Hi all;
 
 We have a large-ish set of cmake files building our project which
 results in various executables, libraries, scripts, etc.  Currently
 these are just left lying where they were created, and all our tests
 etc. expect to find them there.
 
 Then we then have a subsequent script that we run to collect the build
 products into a temporary staging area and create the installation
 packages (RPMs, EXEs, etc.)  Then to run our tests on the packages we
 have to put them in a mode where they expect to find things in those
 release locations instead of the build location.
 
 This is annoying for many reasons and I want to change it so that the
 build installs into the staging area, which has the same layout as the
 package installation, then all our tests will use that layout and our
 packager can just package up that staging area with little extra work.
 I guess that the install capabilities of CMake are the right way to go
 about it.
 
 
 One major concern I have is that everyone has scripts, macros, etc.
 which just run make, or use XCode or MSVC with the default target.  If
 I make this change, then when people forget and run the default target
 instead of the install target they'll be running against the results
 of a previous build (when they did run the install step), not the
 results of the current build (where they forgot to run the install
 step).  Much confusion and swearing will ensue.
 
 It doesn't take hardly any time to do the extra few file copies, so I
 just want to ALWAYS install to the staging area after building.
 
 Is there a way to make it so that the install step is the default step
 selected if you don't provide a different one?
 
 Or is CMake install capability not the right answer for this problem?
 
 Or, is a solution like this one:
 
 http://marc.info/?l=cmakem=130365717914933w=2
 
 still the recommended way to handle a situation like this?  Are there
 more official solutions available?
 
 --
 
 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

[CMake] Running install by default, or alternatives?

[Paul Smith]

Hi all;

We have a large-ish set of cmake files building our project which
results in various executables, libraries, scripts, etc.  Currently
these are just left lying where they were created, and all our tests
etc. expect to find them there.

Then we then have a subsequent script that we run to collect the build
products into a temporary staging area and create the installation
packages (RPMs, EXEs, etc.)  Then to run our tests on the packages we
have to put them in a mode where they expect to find things in those
release locations instead of the build location.

This is annoying for many reasons and I want to change it so that the
build installs into the staging area, which has the same layout as the
package installation, then all our tests will use that layout and our
packager can just package up that staging area with little extra work.
I guess that the install capabilities of CMake are the right way to go
about it.


One major concern I have is that everyone has scripts, macros, etc.
which just run make, or use XCode or MSVC with the default target.  If
I make this change, then when people forget and run the default target
instead of the install target they'll be running against the results
of a previous build (when they did run the install step), not the
results of the current build (where they forgot to run the install
step).  Much confusion and swearing will ensue.

It doesn't take hardly any time to do the extra few file copies, so I
just want to ALWAYS install to the staging area after building.

Is there a way to make it so that the install step is the default step
selected if you don't provide a different one?

Or is CMake install capability not the right answer for this problem?

Or, is a solution like this one:

http://marc.info/?l=cmakem=130365717914933w=2

still the recommended way to handle a situation like this?  Are there
more official solutions available?

--

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