[cmake-developers] [PATCH] Proposed fix for bug 15183

[Marko Kylmämaa]

Hello,

I would like to propose the following fix for bug 15183 (
https://cmake.org/Bug/view.php?id=15183)

For some reason the XcodeGenerator seemed to be setting the INSTALL_PATH
variable regardless of if it was initialized or not (which is done only for
shared libraries). This seems almost certainly undesirable so I've moved
the code inside the shared library check.

The fix is based on v3.4.1 tag.

---
 Source/cmGlobalXCodeGenerator.cxx | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/Source/cmGlobalXCodeGenerator.cxx
b/Source/cmGlobalXCodeGenerator.cxx
index 33babec..089bb47 100644
--- a/Source/cmGlobalXCodeGenerator.cxx
+++ b/Source/cmGlobalXCodeGenerator.cxx
@@ -2329,10 +2329,10 @@ void
cmGlobalXCodeGenerator::CreateBuildSettings(cmTarget& target,
 this->CreateString(format));
 }

-  // Create the INSTALL_PATH attribute.
-  std::string install_name_dir;
   if(target.GetType() == cmTarget::SHARED_LIBRARY)
 {
+ // Create the INSTALL_PATH attribute.
+ std::string install_name_dir;
 // Get the install_name directory for the build tree.
 install_name_dir = gtgt->GetInstallNameDirForBuildTree(configName);
 // Xcode doesn't create the correct install_name in some cases.
@@ -2356,9 +2356,9 @@ void
cmGlobalXCodeGenerator::CreateBuildSettings(cmTarget& target,
   extraLinkOptions += " -install_name ";
   extraLinkOptions += XCodeEscapePath(install_name.c_str());
   }
+ buildSettings->AddAttribute("INSTALL_PATH",
+ this->CreateString(install_name_dir.c_str()));
 }
-  buildSettings->AddAttribute("INSTALL_PATH",
-
 this->CreateString(install_name_dir.c_str()));

   // Create the LD_RUNPATH_SEARCH_PATHS
   cmComputeLinkInformation* pcli = gtgt->GetLinkInformation(configName);
-- 
2.5.4 (Apple Git-61)



*Marko KylmamaaCTO*
*Reforged Studios* 
*Cell:* +1-949-872-9650
*Skype:* mkylmamaa
-- 

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 alternative language

[Charles Huet]

Hi,

> * There is a lot of code out there in the current CMake language so I do
not
  think it is realistic to drop it.  I'm not proposing that this change.

I am. (more below)

> * Many projects build elaborate macro/function systems in the CMake
language
  in order to end up with a declarative specification listing the actual
  source files, dependencies, and usage requirements.  I'd like to offer
  an alternative to this.

In my experience, most of the elaborate macros/functions come either from a
misunderstanding of some of CMake's internals (scope, link debug/release
libs, etc) or to circumvent some shortcoming of the CMake language (e.g. no
return value for functions).

>  I'd like to improve this by *optionally* moving part of the specification
  to a (stateless) declarative format that IDEs can load/edit/save directly

Split the buildsystem in two different languages ? Would the declarative
part be in a different file ?
Also, the declarative part in my opinion must take advantage of the
language.
For instance, add a source file only for WIN32 systems should be easy in
said declarative format.
Using a custom language (based on JSON for instance) would mean to add
conditionals, which comes back to making a custom language again.


To come back to my first point, I understand completely that this would be
a tremendous change, and the transition would be difficult to say the
least. But I think it would be more than worth it in the long term.

> The moment you make CMake scriptable in more than one language, you are
forcing
> every CMake user to learn that additional language because sooner or
later he
> will step into a third-party that is using that additional language.

What I have in mind is to deprecate the current CMake language and replace
it with another language. So there would be a transition period, but in the
end there would only be one language again, and a better one.

If CMake transitioned to python (or Lua, or whatever) newcomers to CMake
would not need learn a new language (or at least learn one that has many
resources, and can be used for other purposes).
Old-timers would have to learn a new language (or maybe not, most
programmers I know have played a bit with python to automate simple tasks),
but this would be easier than learning CMake was, since there are
established rules and a more consistent design to it.

Of course I'm not saying this should happen overnight, nor am I saying this
*must* happen, but I think discussing it can only be beneficial.

I've seen lots of people wonder how to make their CMake scripts more
efficient, and currently this is a very difficult thing to do, since there
is no profiling possible.
And who can say they never spent way too much time trying to understand why
a variable was not correctly initialized ? When the configure step takes
about 30 seconds, and all you can do is use MESSAGE() to find what happens,
this is no walk in the park. A real debugger would do a world of good to
CMake.
I have seen some hardly understandable CMake code, and only thanks to the
git history was I able to understand that the person who wrote the script
completely misunderstood the CMake language.

>As discussed above if some kind of callback or user-coded function needs to
be included for advanced usage of the declarative spec then we would need
a language for it.  The current CMake language is not well suited to that
use case (e.g. no expressions or return values), so an existing alternative
language should be chosen.

>CMake's current "generator expressions" fill this role somewhat now and are
essentially a sub-language.  As with the main language they grew out of
something not intended to serve their current full role.  They could be
superseded by a common alternative generate-time language too.

These points are part of the reason I think a new language should be used,
if it can cover all of these issues. I'd rather not see a new CMake
declarative language that might itself grow out and become something
difficult to grasp.
Something like generator expressions could be expressed in a language such
as python or lua, by using objects that get resolved at generate time (or
functions, or whatever).


Cheers

Le lun. 11 janv. 2016 à 21:53, Brad King  a écrit :

> Hi Folks,
>
> I'm replying directly to my previous post in this thread in order to
> consolidate
> responses to related discussion raised in others' responses to it:
>
>
> http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/15339/focus=15383
>
> http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/15339/focus=15386
>
> http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/15339/focus=15389
>
> General comments:
>
> * There is a lot of code out there in the current CMake language so I do
> not
>   think it is realistic to drop it.  I'm not proposing that this change.
>
> * CMake's procedural/imperative design is good as the main entry point to
>   

[cmake-developers] cmake daemon mode protocol

[Tobias Hunger]

Hi Stephen,

I have successfully build and run your cmake server mode changes and
the python client script does work as advertised.

I do have a couple of remarks about it. This is more intended as a
starting point for discussion as a real proposal. Would something
along these lines be possible:

* Start daemon-mode without any additional parameters

* Daemon responds with "
  {
"type": "handShake",
"version": "3.5.x",
"supportedProtocols": "3.5"
  }

* Client Handshake:
  {
"type": "handshake",
"requestProtocolVersion": "3.5"
  }

* Daemon:
  {
"type:"handshake",
"protocolVersion": "3.5"
  }


At this point the normal operation should be possible.

* Client:
  {
 "type": "setProjectInformation",
 "sourceDirectory": "/some/path",
 "cookie": "1"
  }

  Being able to set the source directory is important so that a fresh
checkout can be configured. There is no build directory available at
that time...

* Daemon should do progress handling while reading the CMakeLists.txt
or whatever it does:
  { "type": "progress", "state": "busy", "task": "someId",
"taskDescription": "Reading CMakeLists.txt files", "cookie": "1" }

* Daemon sends occasional:
  { "type": "progress", "task": "someId", progressTotal: 25,
progressCurrent: 12, "cookie": "1" }

* Daemon sends (probably optional...):
  { "type": "progress", "task": "someId", "state": "done", "cookie": "1" }

* Finally Daemon responds sends data as that is available now.
  {
"type": "projectInformation",
"sourceDirectory": "/some/path",
"buildDirectory": "",
"projectName": "SomeProject",
"cookie": "1"
  }

* Client:
  {
"type": "setProjectInformation",
"buildDirectory": "/some/other/path",
"cookie": "2"
  }

* Daemon does progress indication as above...

* Daemon responds with project info:
  {
"type": "progressInformation",
"sourceDirectory": "/some/path",
"buildDirectory": "/some/other/path",
"projectName": "SomeProject",
"cookie": "2"
  }

We might also want a "ping"/"pong" to detect if the daemon is still
responding. That would require the daemon to be able to handle
multiple requests to be in flight... not sure that this is worth it.
But if we can not do that, then we need to provide constant progress
information, which is also not great:-)

Not sure about the need for cookies (text set by the client and
repeated by the server in all its replies to that request). I do think
having them makes sense, even when only one request can be active at
any time: They make it so much easier to sanity-check communication.

Consistently having a "type" in all messages going back and forth is
probably a good idea for the same reason as having cookies.

A final, remark unrelated to the protocol: Ideally the daemon should
delay writing into (and even creating!) the build directory for as
long as possible (or till instructed to actually persist the
configuration). We do have many users that use Qt Creator to browse
foreign code and those tend to get upset when we write stuff to disk.

Best Regards,
Tobias
-- 

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 alternative language

[Charles Huet]

I don't think this is a dumb question, actually this is part of the problem
I think would be resolved whit a new language.

The barrier of entry to using CMake is too high in my opinion, and I think
using an existing language would lower it *a lot*.

Thanks for sharing :)


Le mer. 13 janv. 2016 à 10:59, yann suisini  a
écrit :

> Hi,
>
> I'm a new user of CMake, but I just want to express my newcomer point of
> view.
> Honestly , I can feel the power of CMAKE, but it's a real pain to learn ...
> I'm using CMAKE for an embedded platform with a non GNU compiler , ant at
> the end the CMAKE description is longer than the one I built directly in
> Ninja.
> I had to write a python script to parse my eclipse project xml to create a
> list of sources files usable by CMAKE.
> The first thing I thought was: why this is not a part of cmake ? And the
> second thing was : why not using the scripting power of an existing
> language like Python(or other one)
> and add CMAKE as a framework / library ?
> Probably a dumb question ! :)
>
> Yann
>
> 2016-01-13 10:34 GMT+01:00 Charles Huet :
>
>> Hi,
>>
>> > * There is a lot of code out there in the current CMake language so I
>> do not
>>   think it is realistic to drop it.  I'm not proposing that this change.
>>
>> I am. (more below)
>>
>> > * Many projects build elaborate macro/function systems in the CMake
>> language
>>   in order to end up with a declarative specification listing the actual
>>   source files, dependencies, and usage requirements.  I'd like to offer
>>   an alternative to this.
>>
>> In my experience, most of the elaborate macros/functions come either from
>> a misunderstanding of some of CMake's internals (scope, link debug/release
>> libs, etc) or to circumvent some shortcoming of the CMake language (e.g. no
>> return value for functions).
>>
>> >  I'd like to improve this by *optionally* moving part of the
>> specification
>>   to a (stateless) declarative format that IDEs can load/edit/save
>> directly
>>
>> Split the buildsystem in two different languages ? Would the declarative
>> part be in a different file ?
>> Also, the declarative part in my opinion must take advantage of the
>> language.
>> For instance, add a source file only for WIN32 systems should be easy in
>> said declarative format.
>> Using a custom language (based on JSON for instance) would mean to add
>> conditionals, which comes back to making a custom language again.
>>
>>
>> To come back to my first point, I understand completely that this would
>> be a tremendous change, and the transition would be difficult to say the
>> least. But I think it would be more than worth it in the long term.
>>
>> > The moment you make CMake scriptable in more than one language, you are
>> forcing
>> > every CMake user to learn that additional language because sooner or
>> later he
>> > will step into a third-party that is using that additional language.
>>
>> What I have in mind is to deprecate the current CMake language and
>> replace it with another language. So there would be a transition period,
>> but in the end there would only be one language again, and a better one.
>>
>> If CMake transitioned to python (or Lua, or whatever) newcomers to CMake
>> would not need learn a new language (or at least learn one that has many
>> resources, and can be used for other purposes).
>> Old-timers would have to learn a new language (or maybe not, most
>> programmers I know have played a bit with python to automate simple tasks),
>> but this would be easier than learning CMake was, since there are
>> established rules and a more consistent design to it.
>>
>> Of course I'm not saying this should happen overnight, nor am I saying
>> this *must* happen, but I think discussing it can only be beneficial.
>>
>> I've seen lots of people wonder how to make their CMake scripts more
>> efficient, and currently this is a very difficult thing to do, since there
>> is no profiling possible.
>> And who can say they never spent way too much time trying to understand
>> why a variable was not correctly initialized ? When the configure step
>> takes about 30 seconds, and all you can do is use MESSAGE() to find what
>> happens, this is no walk in the park. A real debugger would do a world of
>> good to CMake.
>> I have seen some hardly understandable CMake code, and only thanks to the
>> git history was I able to understand that the person who wrote the script
>> completely misunderstood the CMake language.
>>
>> >As discussed above if some kind of callback or user-coded function needs
>> to
>> be included for advanced usage of the declarative spec then we would need
>> a language for it.  The current CMake language is not well suited to that
>> use case (e.g. no expressions or return values), so an existing
>> alternative
>> language should be chosen.
>>
>> >CMake's current "generator expressions" fill this role somewhat now and
>> are
>> essentially a sub-language.  As 

Re: [cmake-developers] Adding Swift support to CMake for Linux/Makefiles

[Eric Wing]

On 1/12/16, Brad King  wrote:
> On 01/08/2016 06:15 PM, Eric Wing wrote:
>> simple 'swiftc' integration going for ADD_EXECUTABLE, as described in
>> the original post.
>
> Take the generator check out of Modules/CMakeDetermineSwiftCompiler.cmake
> to get rid of the up-front error.  See "Modules/CMakeAddNewLanguage.txt"
> (many of the steps are already done).
>
> Edit Modules/CMakeSwiftInformation.cmake and add settings for variables
> like CMAKE_Swift_COMPILE_OBJECT and CMAKE_Swift_LINK_EXECUTABLE.  See
> the CMake{C,CXX,Fortran}Information.cmake modules for examples.  The
> available placeholders are in cmLocalGenerator::ExpandRuleVariable.
>
> If all the compile/link steps used for C and C++ map well to switfc
> then it should be fairly straightforward.  If other steps are needed
> or the steps have wildly different semantics then more in-depth changes
> to the actual generators may be needed.
>
> -Brad
>


So I got the trivial base case working with swiftc (no library
dependencies, Mac for now but will shift to Linux eventually):
add_exectuable(MyTarget main.swift)

Yay.

So next I wanted to add more files to the mix. And now I have some problems.


Problem 1: Intermixing C and Swift
add_exectuable(MyTarget main.swift some_c.c)
Note: I presume C++ (and Obj-C) could also be in the mix:
add_exectuable(MyTarget main.swift some_c.c some_cpp.cpp some_objc.m)

It looks like the link phase is invoking cc on my system (the C linker
rules?) instead of the Swift linker commands.

If my hunch is correct, how do I tell CMake to ‘promote’ Swift as the
correct tool?
(Perhaps there is a similar existing mechanism already is handling
intermixing C/C++ or C/Obj-C?)

Additional note: I am a little surprised to see cc instead of ld (or
swiftc). Now I may be able to use cc or ld, but I need to figure out
how to adapt and add some additional flags. So it could be that I
could work around this problem. (Kind of working solution at the
bottom.)



Problem 2: Multiple Swift files in the target
add_exectuable(MyTarget main.swift OtherSwift.swift)

With two or more files, I was hoping to do a single one-shot call:
swiftc -c OtherSwift.swift main.swift -module-name MyTarget

But it looks like CMake invokes each file separately. The problem that
creates in the above case is that if main.swift uses stuff from the
other file, it can no longer compile because it is unable to find the
code in OtherSwift because they are treated as separate unconnected
modules. I haven’t figured a way yet around this using swiftc.

However, I can switch to the tool ‘swift’, but it looks like Swift has
a similar constraint which I will discuss shortly.

But before I move on to that, is there a way to get CMake to invoke
all the Swift files in the target together? (It would need to exclude
any non-Swift files in the list.)

I think there may be trade-offs here. On one hand, file-by-file might
get us incremental compilation. But there is a flag called
-whole-module-optimization which suggests treating them as a batch
could allow better code generation.


Now for the 'swift' tool:

So the swift tool can go file-by-file, but the additional constraint
is that all the other Swift files in the target must be listed too. To
distinguish which file is actually being processed, you must use the
-primary-file  . I think this is so
Swift can figure out all the cross-file dependencies since there are
no header files in Swift.

Here is an example of compiling my two files:

# Compile main.swift to main.o
swift -frontend -c -primary-file
/Volumes/DataPartition/Users/ewing/Source/CodeTest/CMakeSwiftBasic/main.swift
/Volumes/DataPartition/Users/ewing/Source/CodeTest/CMakeSwiftBasic/OtherSwift.swift
-emit-module -module-name MyTarget  -o CMakeFiles/MyApp.dir/main.o
-emit-module-path CMakeFiles/MyApp.dir/main~partial.swiftmodule

# Compile OtherSwift.swift to OtherSwift.o
swift -frontend -c -primary-file
/Volumes/DataPartition/Users/ewing/Source/CodeTest/CMakeSwiftBasic/OtherSwift.swift
/Volumes/DataPartition/Users/ewing/Source/CodeTest/CMakeSwiftBasic/main.swift
-emit-module -module-name MyTarget  -o
CMakeFiles/MyApp.dir/OtherSwift.o -emit-module-path
CMakeFiles/MyApp.dir/OtherSwift~partial.swiftmodule

Other things to notice:
- I am using the CMake Target Name for the -module-name
- There is a basename~partial.swiftmodule being generated. I'm not
completely sure why this is needed, but I see it in the Xcode build
lines and other examples on the web.


Finally, the link line can look like this: (Xcode invokes clang
instead of cc, but they map to the same thing on Mac)

/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc
 -arch x86_64 -isysroot
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk
-L/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift_static/macosx
-Xlinker -force_load_swift_libs -lswiftRuntime -lc++ -framework

Re: [cmake-developers] CMake alternative language

[Saša Janiška]

On Sri, 2016-01-13 at 13:14 +, Charles Huet wrote:

> I don't think this is a dumb question, actually this is part of the
> problem I think would be resolved whit a new language.
> 
> The barrier of entry to using CMake is too high in my opinion, and I
> think using an existing language would lower it *a lot*.

Personally I'm determinant to use CMake, mostly due to its maturity and 
CPack's features, but recently stumbled upon Meson http://mesonbuild.com/) 
build system whose goal is "to be both extremely fast, and, even more 
importantly, as user friendly as possible."...it also uses Ninja instead 
of Make as backend.

Otoh, I believe that main problem with CMake is lack of quality docs - even 
Mastering CMake book has constantly very bad reviews.

Sincerely,
Gour


-- 
One who sees inaction in action, and action in inaction, 
is intelligent among men, and he is in the transcendental position, 
although engaged in all sorts of activities.




-- 

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] Assertion hit in CMake for KDevelop on Ubuntu

[Alexander Neundorf]

On Wednesday, January 13, 2016 10:16:23 Robert Dailey wrote:
> Running version 3.2.2 on Ubuntu 15. I run the following command:
> 
> $ cmake .. -G"KDevelop3" -DCMAKE_C_COMPILER=gcc-4.9
> -DCMAKE_CXX_COMPILER=g++-4.9 -DCMAKE_BUILD_TYPE=$config
> -DCMAKE_TOOLCHAIN_FILE="../toolchains/linux_i686.toolchain.cmake"

are you sure you actually want to use the KDevelop3 generator ?
This is for the KDE3 version, and you are probably using the KDE4 version of 
KDevelop ? For that you don't need these generated project files.

Actually I was thinking about removing this generator, because KDevelop3 is 
really really old, not sure whether it is still available in current Linux 
distributions.

Alex

-- 

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-developers] [CMake 0015916]: [Buildroot] [PATCH] cmake: use system libzma when the xz package is enabled

[Mantis Bug Tracker]

The following issue has been SUBMITTED. 
== 
https://cmake.org/Bug/view.php?id=15916 
== 
Reported By:R Jones
Assigned To:
== 
Project:CMake
Issue ID:   15916
Category:   CMake
Reproducibility:always
Severity:   tweak
Priority:   normal
Status: new
== 
Date Submitted: 2016-01-13 14:17 EST
Last Modified:  2016-01-13 14:17 EST
== 
Summary:[Buildroot] [PATCH] cmake: use system libzma when
the xz package is enabled
Description: 
I have XZ installed already.
I was trying to compile cmake using gmake and GCC4.

The error is:
Fix build failure:
.../output/build/host-cmake-3.1.3/Utilities/cmliblzma/liblzma/common/block_buffer_decoder.c:17:1:
error: conflicting types for ‘lzma_block_buffer_decode’
 lzma_block_buffer_decode(lzma_block *block, lzma_allocator *allocator,
 ^
In file included from
/home/tetsuya/buildroot/br2/output/host/usr/include/lzma.h:296:0,
 from
/home/tetsuya/buildroot/br2/output/build/host-cmake-3.1.3/Utilities/cmliblzma/liblzma/common/common.h:34,
 from
/home/tetsuya/buildroot/br2/output/build/host-cmake-3.1.3/Utilities/cmliblzma/liblzma/common/block_decoder.h:16,
 from
/home/tetsuya/buildroot/br2/output/build/host-cmake-3.1.3/Utilities/cmliblzma/liblzma/common/block_buffer_decoder.c:13:
/home/tetsuya/buildroot/br2/output/host/usr/include/lzma/block.h:577:27: note:
previous declaration of ‘lzma_block_buffer_decode’ was here
 extern LZMA_API(lzma_ret) lzma_block_buffer_decode(
   ^
Utilities/cmliblzma/CMakeFiles/cmliblzma.dir/build.make:261: recipe for target
'Utilities/cmliblzma/CMakeFiles/cmliblzma.dir/liblzma/common/block_buffer_decoder.c.o'
failed
make[3]: ***
[Utilities/cmliblzma/CMakeFiles/cmliblzma.dir/liblzma/common/block_buffer_decoder.c.o]
Error 1

Steps to Reproduce: 
On a Solaris system with with GCC4, GMAKE, ZLIB, EXPAT, BZIP2, CURL, XZ and
without cmake installed:

CFLAGS=-I{INSTARGET}/include

bash ./configure \
--prefix=${INSTARGET} \
--system-zlib \
--system-expat \
--system-bzip2 \
--system-curl

Causes the problem in the description.

After patching bootstrap (see below), I was able to clear the problem with:
bash ./configure \
--prefix=${INSTARGET} \
--system-zlib \
--system-expat \
--system-bzip2 \
--system-liblzma \
--system-curl

Additional Information: 
I found this thread when looking into how to disable cmake build from trying to
include it's own liblzma instead of the system liblzma.  It seems that the
engine is prepared for it, but bootstrap does not allow --system-liblzma as an
option.  All I needed to do to disable the internal copy was to add this to
bootstrap and re-run configure:

$ diff bootstrap bootstrap.orig
652c652
<  
--system-bzip2|--system-curl|--system-expat|--system-jsoncpp|--system-libarchive|--system-zlib|--system-liblzma)
---
>  
--system-bzip2|--system-curl|--system-expat|--system-jsoncpp|--system-libarchive|--system-zlib)

Also would need to update the "help"

Is there some reason this option could not be added to the package?
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-01-13 14:17 R JonesNew Issue
==

-- 

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] Assertion hit in CMake for KDevelop on Ubuntu

[Robert Dailey]

On Wed, Jan 13, 2016 at 12:36 PM, Brad King  wrote:
> On 01/13/2016 11:16 AM, Robert Dailey wrote:
>> Running version 3.2.2 on Ubuntu 15. I run the following command:
> [snip]
>> cmake: ../../Source/cmTarget.cxx:722: void
>> cmTarget::GetSourceFiles(std::vector>> &, const string&) const: Assertion `this->GetType() !=
>> INTERFACE_LIBRARY' failed.
>> ../frontend/Core/CMake/helper-scripts/kdevelop-linux.sh: line 13:
>> 21545 Aborted (core dumped) cmake "$DIR/../../.."
>
> Please try running with CMake 3.4 or 'master' to see if it still
> happens.  There has been substantial refactoring of this code
> since 3.2.
>
> Thanks,
> -Brad
>

3.4 isn't available to me on Ubuntu 15; do you have a custom PPA I can
add to grab the latest CMake debian package?
-- 

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] Assertion hit in CMake for KDevelop on Ubuntu

[Brad King]

On 01/13/2016 11:16 AM, Robert Dailey wrote:
> Running version 3.2.2 on Ubuntu 15. I run the following command:
[snip]
> cmake: ../../Source/cmTarget.cxx:722: void
> cmTarget::GetSourceFiles(std::vector> &, const string&) const: Assertion `this->GetType() !=
> INTERFACE_LIBRARY' failed.
> ../frontend/Core/CMake/helper-scripts/kdevelop-linux.sh: line 13:
> 21545 Aborted (core dumped) cmake "$DIR/../../.."

Please try running with CMake 3.4 or 'master' to see if it still
happens.  There has been substantial refactoring of this code
since 3.2.

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

Re: [cmake-developers] Assertion hit in CMake for KDevelop on Ubuntu

[Kevin Funk]

On Wednesday, January 13, 2016 12:44:59 PM Robert Dailey wrote:
> On Wed, Jan 13, 2016 at 12:36 PM, Brad King  wrote:
> > On 01/13/2016 11:16 AM, Robert Dailey wrote:
> >> Running version 3.2.2 on Ubuntu 15. I run the following command:
> > [snip]
> > 
> >> cmake: ../../Source/cmTarget.cxx:722: void
> >> cmTarget::GetSourceFiles(std::vector >> 
> >>> &, const string&) const: Assertion `this->GetType() !=
> >> 
> >> INTERFACE_LIBRARY' failed.
> >> ../frontend/Core/CMake/helper-scripts/kdevelop-linux.sh: line 13:
> >> 21545 Aborted (core dumped) cmake "$DIR/../../.."
> > 
> > Please try running with CMake 3.4 or 'master' to see if it still
> > happens.  There has been substantial refactoring of this code
> > since 3.2.
> > 
> > Thanks,
> > -Brad
> 
> 3.4 isn't available to me on Ubuntu 15; do you have a custom PPA I can
> add to grab the latest CMake debian package?

There are pre-built binaries here:
  https://cmake.org/download/

I also use them on Ubuntu, no issues.

Cheers,
Kevin

-- 
Kevin Funk | kf...@kde.org | http://kfunk.org

signature.asc
Description: This is a digitally signed message part.
-- 

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 alternative language

[Alexander Neundorf]

On Wednesday, January 13, 2016 10:59:39 yann suisini wrote:
> Hi,
> 
> I'm a new user of CMake, but I just want to express my newcomer point of
> view.
> Honestly , I can feel the power of CMAKE, but it's a real pain to learn ...
> I'm using CMAKE for an embedded platform with a non GNU compiler , ant at
> the end the CMAKE description is longer than the one I built directly in
> Ninja.
> I had to write a python script to parse my eclipse project xml to create a
> list of sources files usable by CMAKE.
> The first thing I thought was: why this is not a part of cmake ? And the
> second thing was : why not using the scripting power of an existing
> language like Python(or other one) and add CMAKE as a framework / library ?

My personal opinion: if the full power of python would be available, the build 
scripts would quickly turn into real programs, because programmers would be 
tempted to do so if all of python would be available. Then developers would 
have to understand two programs: the program itself, and the "build program".

I'm not saying that the cmake language is beautiful, but it helps to keep 
cmake scripts somewhat simple, and not evolve into a second program 
additionally to the actual program which is being built.

Alex

-- 

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] Assertion hit in CMake for KDevelop on Ubuntu

[Rolf Eike Beer]

Am Mittwoch, 13. Januar 2016, 12:44:59 schrieb Robert Dailey:
> On Wed, Jan 13, 2016 at 12:36 PM, Brad King  wrote:
> > On 01/13/2016 11:16 AM, Robert Dailey wrote:
> >> Running version 3.2.2 on Ubuntu 15. I run the following command:
> > [snip]
> > 
> >> cmake: ../../Source/cmTarget.cxx:722: void
> >> cmTarget::GetSourceFiles(std::vector >> 
> >>> &, const string&) const: Assertion `this->GetType() !=
> >> 
> >> INTERFACE_LIBRARY' failed.
> >> ../frontend/Core/CMake/helper-scripts/kdevelop-linux.sh: line 13:
> >> 21545 Aborted (core dumped) cmake "$DIR/../../.."
> > 
> > Please try running with CMake 3.4 or 'master' to see if it still
> > happens.  There has been substantial refactoring of this code
> > since 3.2.

> 3.4 isn't available to me on Ubuntu 15; do you have a custom PPA I can
> add to grab the latest CMake debian package?

https://cmake.org/files/v3.4/cmake-3.4.1-Linux-i386.tar.gz

Extract it whereever you like, then point the PATH variable to it.

Greetings,

Eike

signature.asc
Description: This is a digitally signed message part.
-- 

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] Adding Swift support to CMake for Linux/Makefiles

[Eric Wing]

> For the moment, I like swiftc over swift because it seems a lot
> simpler. I hope this means the least changes for CMake right now.

I need to correct myself on this. While I like swiftc for looking
simpler, I'm actually thinking swift might be fewer changes since the
file-by-file thing is what CMake does today.
It may turn out swift is easier to figure out in the end too when we
eventually look at add_library and linking them (since we can reverse
engineer from the Xcode logs).

But either way, both of them seem to need SOURCES.

Thanks,
Eric
-- 

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] Adding Swift support to CMake for Linux/Makefiles

[Eric Wing]

>> If my hunch is correct, how do I tell CMake to ‘promote’ Swift as the
>> correct tool?
>
> See the CMAKE__LINKER_PREFERENCE platform information variable.
> There is also the LINKER_LANGUAGE target property.  For C, C++, and
> Fortran one generally chooses between C++ and Fortran to drive the
> linker based on which language has the entry point (main) in its
> sources.  If we see a "main.swift" then we know Swift should be used.
> If not then I don't know enough about Swift linking requirements to say.

I suspect it is like C++ and C. If there is both, you promote up to C++ linking.
So if there is any .swift file or library in the mix, you need to
promote up to use Swift.

Under the hood, I think the LLVM linker can handle all of these
through ld. But I think the thing that is tripping me up is that Swift
seems to need to link against some additional libraries which are not
needed in the pure C case. The swiftc command seems to know how to
automatically link in those extra dependencies (and I don't need to
add all the search paths to where the Swift core libraries are
located).

Anyway, I tried bumping up CMAKE_Swift_LINKER_PREFERENCE to 40. (Same
as Java). But it didn't seem to do anything for me.

I then added to my test CMakeLists.txt:
set_property(TARGET MyApp PROPERTY LINKER_LANGUAGE Swift)

That then worked, but I'm confused how to get CMake to automatically
do this for me because I expected CMAKE_Swift_LINKER_PREFERENCE to do
this.


>
> This looks like a semantic difference between how the switfc and cc
> compilers work that as I feared in my previous response may require
> C++ changes to CMake to make work.  Before diving into that we need
> to understand the preferred way to compile multiple Swift sources.
> Last time I looked at this the only reference was "what Xcode does".
> Hopefully there is more information out there now.

Unfortunately, there isn't a whole lot more information. The majority
of the examples are hello world programs with one file.

The best write up I've seen is this series:
http://owensd.io/blog/compiling-swift-without-xcode/
http://owensd.io/blog/compiling-individual-files/
http://owensd.io/blog/swift-vs-swiftc/
http://owensd.io/blog/swift-makefiles---take-2/

One interesting note, swiftc is just an alias for swift.


The exception is the Swift Package manager. But this is a convention
based system. Right now it is far from finished and its conventions
are actually incompatible with Xcode. It has its own file format and
also requires all dependency packages be in a Git repo and follow a
certain tagging convention. I also haven't seen any way to directly
mix C+Swift code in a module and they expect you to create a separate
module for C stuff which you then import in. I'm under the impression
they plan to relax a lot of these things, but I find it currently too
incomplete and with too much impedance to be useful right now.

(By the way, I think I'm a little incorrect about main.swift being
special. I'm seeing examples where they name the file anything.swift.
It looks like Swift will automatically create a main entry point for
you when building an executable, especially in the one-shot case. With
swiftc it must be a one-shot otherwise you get duplicate symbols. With
swift -frontend, it some how manages to create one. But with the Swift
Package system, I think main.swift is a convention-requirement.)



> It may be that we're supposed to invoke Swift with all sources at once
> and let it take responsibility for generating the results and doing any
> kind of incremental stuff internally.

So Xcode is using the swift -frontend technique and it looks like it
doing it incrementally. I think the requirement for the list of other
files is so it can resolve the dependencies.


> It shouldn't be too hard to add a  placeholder if needed.  We
> may need it either way because we either list all the sources on one
> call to swift or on every call to swift.

Right.

>> - Also, for the second , I need to remove the one I'm using
>> from my -primary-file. And there shouldn't be any non-Swift files in
>> the list (no C/C++/Obj-C).
>
> That kind of filtering may be harder to define and require custom logic
> in CMake's generators for Swift instead of trying to do it with generic
> placeholders.

I just tried not filtering the current primary file from the list. It
still worked. So maybe we can get away with not filtering that.
However, we do need to filter any C files. That didn't work. (It tried
to compile those .c files as Swift which obviously won't work.)



>> Can you give me some suggestions on what to look at next?
>
> Before proceeding with CMake changes I think we need a better
> understanding of the tools involved in Swift development.  What
> does individual compilation achieve over monolithic compilation?

I'm actually not sure. The monolithic one-shot should avoid any
potential incorrectness problems if a dependent file was changed but a
calling file wasn't recompiled. I don't 

[cmake-developers] [CMake 0015917]: Visual Studio project files generated incorrectly

[Mantis Bug Tracker]

The following issue has been SUBMITTED. 
== 
https://cmake.org/Bug/view.php?id=15917 
== 
Reported By:Daniel Williams
Assigned To:
== 
Project:CMake
Issue ID:   15917
Category:   CMake
Reproducibility:always
Severity:   major
Priority:   normal
Status: new
== 
Date Submitted: 2016-01-13 18:16 EST
Last Modified:  2016-01-13 18:16 EST
== 
Summary:Visual Studio project files generated incorrectly
Description: 
Executables are incorrectly flagged as Application executables (i.e. to use
winMain) instead of utility / console executables (and use the normal main)

when cmake is generating solution (.sln) and project (.vcxproj) files for Visual
Studio, it cannot set the flags correctly.  The generator creates: 
Application

Instead of:
Utility

This in turn causes compile-time Link Errors 

As it should.  This is controlled by a flag on the executable. (or so says the
documentation): 
[1]https://cmake.org/cmake/help/v3.4/command/add_executable.html
[2]https://cmake.org/cmake/help/v3.4/prop_tgt/WIN32_EXECUTABLE.html






Steps to Reproduce: 
1) create empty project with supplied CMakeLists.txt
2) create a minimal 'main.cpp'  (contents don't matter, empty should be fine)
3) run configure ; run generate
4) inspect $BUILD_DIR/test.exe.vcxproj
   DOM: Project/PropertyGroup/ConfigurationType values will all still be set to
"Application" which requires the winmain symbol be defined.  

This Application tag is generated both with and without the WIN32 flag.  It is
only supposed to be generated *with*.  (Without the flag, the
'ConfigurationType' tag should be set to 'Utility', the console exe version.)

Additional Information: 
1) Originally Reproduced as far back as CMake 3.1.2
2) the 'set_executable(...)' function correctly sets the flag, as checked by
'get_target_property(...)', but this property does not carry through to the file
generation stage.
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-01-13 18:16 Daniel WilliamsNew Issue
2016-01-13 18:16 Daniel WilliamsFile Added: CMakeLists.txt
==

-- 

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-developers] [CMake 0015915]: add_subdirectory(directory EXPORT_VARIABLES VAR_1 VAR_2) gives "add_subdirectory called with incorrect number of arguments"

[Mantis Bug Tracker]

The following issue has been SUBMITTED. 
== 
https://cmake.org/Bug/view.php?id=15915 
== 
Reported By:Bryan Koch
Assigned To:
== 
Project:CMake
Issue ID:   15915
Category:   CMake
Reproducibility:always
Severity:   minor
Priority:   low
Status: new
== 
Date Submitted: 2016-01-13 11:25 EST
Last Modified:  2016-01-13 11:25 EST
== 
Summary:add_subdirectory(directory EXPORT_VARIABLES VAR_1
VAR_2) gives "add_subdirectory called with incorrect number of arguments"
Description: 
As per, https://cmake.org/pipermail/cmake/2005-September/007204.html

ADD_SUBDIRECTORY(directory EXPORT VARIABLES VAR_FOO1 VAR_FOO2) should export
variables from the child scope into the parent scope.

It was implemented by Ken Martin as per below
https://cmake.org/Bug/bug_relationship_graph.php?bug_id=2221=relation
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-01-13 11:25 Bryan Koch New Issue
==

-- 

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-developers] Assertion hit in CMake for KDevelop on Ubuntu

[Robert Dailey]

Running version 3.2.2 on Ubuntu 15. I run the following command:

$ cmake .. -G"KDevelop3" -DCMAKE_C_COMPILER=gcc-4.9
-DCMAKE_CXX_COMPILER=g++-4.9 -DCMAKE_BUILD_TYPE=$config
-DCMAKE_TOOLCHAIN_FILE="../toolchains/linux_i686.toolchain.cmake"



My toolchain file is specified as follows:

set(CMAKE_SYSTEM_NAME Linux)
set(CMAKE_SYSTEM_VERSION 1)
set(CMAKE_SYSTEM_PROCESSOR "i686")

set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -m32" CACHE STRING "c++ flags")
set(CMAKE_C_FLAGS   "${CMAKE_C_FLAGS} -m32" CACHE STRING "c flags")



I get the following output when I generate for KDevelop. Why is CMake
not properly generating my projects? Based on what the assertion says,
I do actually define some interface libraries, mostly to create
"dummy" targets for my third party libraries. If I have a library with
only headers and no binaries or libs, I will make them as interface
libraries. I will post a sample of this below the output below.

-- The C compiler identification is GNU 4.9.3
-- The CXX compiler identification is GNU 4.9.3
-- Check for working C compiler: /usr/bin/gcc-4.9
-- Check for working C compiler: /usr/bin/gcc-4.9 -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/g++-4.9
-- Check for working CXX compiler: /usr/bin/g++-4.9 -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Generating copy_dlls for configurations: Debug
-- + UI> Core/UI/CMakeLists.txt
-- + WebServices   > Core/WebServices/CMakeLists.txt
-- + Barcode   > Core/Barcode/CMakeLists.txt
-- + TestUtils > Core/UI/TestUtils/CMakeLists.txt
-- + DynamicUI > Applications/DynamicUI/CMakeLists.txt
-- + OrderEntry> Applications/OrderEntry/CMakeLists.txt
-- + PATT  > Applications/PATT/CMakeLists.txt
-- + EmailClub > Applications/EmailClub/CMakeLists.txt
-- + Survey> Applications/Survey/CMakeLists.txt
-- + SettingsManager   > Applications/SettingsManager/CMakeLists.txt
-- + zFacebook > Applications/zFacebook/CMakeLists.txt
-- + Loyalty   > Applications/Loyalty/CMakeLists.txt
-- + MessagingModule   > Applications/MessagingModule/CMakeLists.txt
-- + zApp  > Applications/zApp/CMakeLists.txt
-- + zApp_Library  > Applications/zApp/CMakeLists.txt
-- Configuring done
cmake: ../../Source/cmTarget.cxx:722: void
cmTarget::GetSourceFiles(std::vector&, const string&) const: Assertion `this->GetType() !=
INTERFACE_LIBRARY' failed.
../frontend/Core/CMake/helper-scripts/kdevelop-linux.sh: line 13:
21545 Aborted (core dumped) cmake "$DIR/../../.."
-G"KDevelop3" -DCMAKE_C_COMPILER=gcc-4.9 -DCMAKE_CXX_COMPILER=g++-4.9
-DCMAKE_BUILD_TYPE=$config
-DCMAKE_TOOLCHAIN_FILE="$DIR/../toolchains/linux_i686.toolchain.cmake"



Sample of how I define interface libraries (contents of one of my
CMakeLists.txt):

set( project_name Catch )
add_library( ${project_name} INTERFACE )
target_include_directories( ${project_name} INTERFACE include )
-- 

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] Why does INTERFACE type targets only support whitelisted properties?

[Ben Boeckel]

On Mon, Jan 11, 2016 at 16:47:03 -0500, Taylor Braun-Jones wrote:
> I have another INTERFACE property use case that is not whitelisted, but
> should be: VERSION

VERSION is a special property for libraries. Particularly the name for
the file with the actual content of the library (the SOVERSION and name
of the library being symlinks to it):

https://cmake.org/cmake/help/latest/prop_tgt/VERSION.html

INTERFACE targets have no need for this property.

> Consider library project Foo that uses a header-only project Bar. In
> FooConfig.cmake, it is a important to ensure any projects using Foo also
> use the exact same version of Bar that Foo was originally built with
> (Failure to do so can lead to subtle, hard-to-find bugs like violation of
> the one definition rule). Assuming project Bar creates an imported target
> "Bar" with a VERSION property set like:
> 
>   set_property(TARGET Bar APPEND PROPERTY VERSION 1.2.3)

Also, this property is not a list (probably?), so APPEND isn't really
correct. It indicates that the value here should be (list-)appended to
the existing value.

> Then project Foo should be able to have something like:
> 
> == CMakeLists.txt ==
> ...
> get_property(FOO_BAR_VERSION TARGET BAR PROPERTY VERSION)
> configure_file(FooConfig.cmake.in FooConfig.cmake @ONLY)
> 
> == FooConfig.cmake.in ==
> ...
> find_package(Bar "@FOO_BAR_VERSION@" EXACT REQUIRED)

find_package(Foo) should set a Foo_VERSION variable (if known):


https://cmake.org/cmake/help/latest/manual/cmake-packages.7.html#package-version-file

> But, alas, this is not currently possible. I'm ambivalent about whether
> INTERFACE properties should be whitelisted vs blacklisted vs unrestricted,
> but at least this VERSION property seems valid to allow.

Currently, they are whitelisted, but I think any property not understood
by CMake directly (i.e., user-set properties) would probably be fine.

--Ben
-- 

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] Allowing generator expressions in install DIRECTORY

[Brad King]

On 01/12/2016 04:34 PM, Yves Frederix wrote:
> I am attaching a patch that adds support for generator expressions in
> the DIRECTORY arguments of install(DIRECTORY ...). It is my first
> contribution

Very nice!  The impl, docs, and tests all look good.  Applied with
minor whitespace tweak and a release note update:

 install: Allow generator expressions in DIRECTORY
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=630c8aa8

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