[cmake-developers] cmake server to cmake file api swicth

[Eric Noulard]

Hi there,

I saw that CMake was apparently switching from CMake server mode (
https://cmake.org/cmake/help/v3.14/manual/cmake-server.7.html) to file api (
https://cmake.org/cmake/help/v3.14/manual/cmake-file-api.7.html).

I first saw it in CMake 3.14 rc and final announce:
https://cmake.org/pipermail/cmake/2019-March/069155.html

However I didn't see much discussion about that on either developer or user
ML beside recent statement from Brad
https://cmake.org/pipermail/cmake-developers/2019-March/031129.html
telling that server mode will certainly be deprecated in favor of file api.

Can any CMake developer that has been participating in this new file api
shed some light on the rational of this foreseen switch?
I'm just curious about it. What was wrong/problematic with server mode?
Does the new file api solves some IDE integration issue?

-- 
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:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] Idea for Multi-Toolchain Support

[Eric Noulard]

Le lun. 17 déc. 2018 à 22:04, Eric Noulard  a
écrit :

> Hi Kyle,
>
> Is your proposal a follow-up on the initial bunch of ideas launched in
> this thread launch by Eike in November
> https://cmake.org/pipermail/cmake-developers/2018-November/030913.html
> with follow-up ideas in in december:
> https://cmake.org/pipermail/cmake-developers/2018-December/030920.html
>
> or is it somehow unrelated?
>
>
> Le lun. 17 déc. 2018 à 21:18, Kyle Edwards via cmake-developers <
> cmake-developers@cmake.org> a écrit :
>
>> Hello everyone,
>>
>> One of the things that's long been requested of CMake is the ability to
>> have multiple toolchains - for instance, one host toolchain and one
>> cross toolchain, so that "utilities" needed for build can be built with
>> the host toolchain and then the "real" software can be built with the
>> cross toolchain.
>>
>> To solve this problem, I would like to propose the creation of a new
>> first-class object type, the "toolchain" type, which would replace the
>> current variable-based system, similar to how imported targets replaced
>> variable-based usage requirements.
>>
>> Every project would automatically receive one toolchain, the "DEFAULT"
>> toolchain, which would be either automatically configured or configured
>> based on CMAKE_TOOLCHAIN_FILE, just like the current system. New
>> toolchains could be added with the add_toolchain() command:
>>
>> add_toolchain(CrossToolchain FILE /path/to/toolchain/file.cmake)
>>
>
> This has some common design issue as my proposal:
> enable_cross_target(...)
> for which Eike has valuable doubt:
> https://cmake.org/pipermail/cmake-developers/2018-November/030919.html
>
>
>> Then, executables and libraries could have a toolchain specified:
>>
>> add_executable(BuildUtility TOOLCHAIN DEFAULT ...)
>> add_library(MyLibrary TOOLCHAIN CrossToolchain ...)
>>
>> Note that the TOOLCHAIN argument is optional, and if omitted, the
>> DEFAULT toolchain is used.
>>
>
> So if you want to build both for host and cross toolchain you'll have to
> explicitely
> add_executable/library(MyLibrary TOOLCHAIN DEFAULT)
> add_executable/library(MyLibrary TOOLCHAIN CrossToolchain)
>
> If you follow the previously referred discussion you cannot assume that
> one lib/exe
> built for a toolchain is not built for another toolchain as well.
>
> How do you envision the cross-toolchain target dependency which was
> a question raised several time.
>
>
>> If a project uses multiple toolchains, we could have the option to
>> rename the default toolchain with an alternative add_toolchain()
>> syntax:
>>
>> add_toolchain(HostToolchain DEFAULT)
>>
>> Rather than adding a new toolchain, this would simply rename the
>> "DEFAULT" toolchain to "HostToolchain". Then the toolchain
>> specification for each target could look like this:
>>
>> add_executable(BuildUtility TOOLCHAIN HostToolchain ...)
>> add_library(MyLibrary TOOLCHAIN CrossToolchain ...)
>>
>> Two new global read-only properties would be added: TOOLCHAINS and
>> DEFAULT_TOOLCHAIN. TOOLCHAINS would be a semicolon-separated list of
>> all registered toolchains, and DEFAULT_TOOLCHAIN would be the name of
>> the DEFAULT toolchain (which could be changed with the alternative
>> add_toolchain() syntax.)
>>
>> The CMAKE_TOOLCHAIN_FILE format would be changed so that rather than
>> setting variables:
>>
>> set(CMAKE_C_COMPILER /usr/bin/gcc)
>> set(CMAKE_C_COMPILER_ID gnu)
>> # etc.
>>
>> it would instead set properties on the selected toolchain:
>>
>> set_property(TOOLCHAIN ${CMAKE_SELECTED_TOOLCHAIN} PROPERTY C_COMPILER
>> /usr/bin/gcc)
>> set_property(TOOLCHAIN ${CMAKE_SELECTED_TOOLCHAIN} PROPERTY
>> C_COMPILER_ID gnu)
>> # etc.
>>
>
> I don't see why we should change the syntax of current toolchain file, I
> don't see the benefit.
> CMake already knows when (and which) toolchain file is loaded and it could
> perfectly automatically
>

... sorry wrong key pressed...

CMake could perfectly automatically create the new "TOOLCHAIN" object by
loading the very
same toolchain file as we have today. We could simple add a new variable
CMAKE_TOOLCHAIN_NAME in that file so that CMake (and the user) can name
them as he wants.
When there is no CMAKE_TOOLCHAIN_NAME this would be the default toolchain.


-- 
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:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] Idea for Multi-Toolchain Support

[Eric Noulard]

Hi Kyle,

Is your proposal a follow-up on the initial bunch of ideas launched in this
thread launch by Eike in November
https://cmake.org/pipermail/cmake-developers/2018-November/030913.html
with follow-up ideas in in december:
https://cmake.org/pipermail/cmake-developers/2018-December/030920.html

or is it somehow unrelated?


Le lun. 17 déc. 2018 à 21:18, Kyle Edwards via cmake-developers <
cmake-developers@cmake.org> a écrit :

> Hello everyone,
>
> One of the things that's long been requested of CMake is the ability to
> have multiple toolchains - for instance, one host toolchain and one
> cross toolchain, so that "utilities" needed for build can be built with
> the host toolchain and then the "real" software can be built with the
> cross toolchain.
>
> To solve this problem, I would like to propose the creation of a new
> first-class object type, the "toolchain" type, which would replace the
> current variable-based system, similar to how imported targets replaced
> variable-based usage requirements.
>
> Every project would automatically receive one toolchain, the "DEFAULT"
> toolchain, which would be either automatically configured or configured
> based on CMAKE_TOOLCHAIN_FILE, just like the current system. New
> toolchains could be added with the add_toolchain() command:
>
> add_toolchain(CrossToolchain FILE /path/to/toolchain/file.cmake)
>

This has some common design issue as my proposal:
enable_cross_target(...)
for which Eike has valuable doubt:
https://cmake.org/pipermail/cmake-developers/2018-November/030919.html


> Then, executables and libraries could have a toolchain specified:
>
> add_executable(BuildUtility TOOLCHAIN DEFAULT ...)
> add_library(MyLibrary TOOLCHAIN CrossToolchain ...)
>
> Note that the TOOLCHAIN argument is optional, and if omitted, the
> DEFAULT toolchain is used.
>

So if you want to build both for host and cross toolchain you'll have to
explicitely
add_executable/library(MyLibrary TOOLCHAIN DEFAULT)
add_executable/library(MyLibrary TOOLCHAIN CrossToolchain)

If you follow the previously referred discussion you cannot assume that one
lib/exe
built for a toolchain is not built for another toolchain as well.

How do you envision the cross-toolchain target dependency which was
a question raised several time.


> If a project uses multiple toolchains, we could have the option to
> rename the default toolchain with an alternative add_toolchain()
> syntax:
>
> add_toolchain(HostToolchain DEFAULT)
>
> Rather than adding a new toolchain, this would simply rename the
> "DEFAULT" toolchain to "HostToolchain". Then the toolchain
> specification for each target could look like this:
>
> add_executable(BuildUtility TOOLCHAIN HostToolchain ...)
> add_library(MyLibrary TOOLCHAIN CrossToolchain ...)
>
> Two new global read-only properties would be added: TOOLCHAINS and
> DEFAULT_TOOLCHAIN. TOOLCHAINS would be a semicolon-separated list of
> all registered toolchains, and DEFAULT_TOOLCHAIN would be the name of
> the DEFAULT toolchain (which could be changed with the alternative
> add_toolchain() syntax.)
>
> The CMAKE_TOOLCHAIN_FILE format would be changed so that rather than
> setting variables:
>
> set(CMAKE_C_COMPILER /usr/bin/gcc)
> set(CMAKE_C_COMPILER_ID gnu)
> # etc.
>
> it would instead set properties on the selected toolchain:
>
> set_property(TOOLCHAIN ${CMAKE_SELECTED_TOOLCHAIN} PROPERTY C_COMPILER
> /usr/bin/gcc)
> set_property(TOOLCHAIN ${CMAKE_SELECTED_TOOLCHAIN} PROPERTY
> C_COMPILER_ID gnu)
> # etc.
>

I don't see why we should change the syntax of current toolchain file, I
don't see the benefit.
CMake already knows when (and which) toolchain file is loaded and it could
perfectly automatically


>
> where CMAKE_SELECTED_TOOLCHAIN is a variable passed to the toolchain
> file either at the root or by the add_toolchain() command.
>
> If you want to read the value of C_COMPILER, etc. then just use
> get_property():
>
> get_property(c_compiler TOOLCHAIN HostToolchain PROPERTY C_COMPILER)
>
> Obviously this system would scale well to more than just two toolchains
> - just use as many add_toolchain() commands as you need.
>
> Backwards compatibility is going to be a challenge. Both the toolchain
> file and the project have to be aware of the new toolchain system,
> which means we have to handle four permutations:
>
> 1) old toolchain + old project
> 2) old toolchain + new project
> 3) new toolchain + old project
> 4) new toolchain + new project
>
> I propose adding a policy that both the toolchain file and the project
> can set separately, and which would have a slightly different meaning
> in each one. If the toolchain is OLD and the project is NEW, then the
> variables set by the toolchain file would be converted into properties
> on the toolchain for the project. If the toolchain is NEW and the
> project is OLD, then the properties on the toolchain would be converted
> into variables in the project. If both the toolchain and project have
> the same value, then no special 

Re: [cmake-developers] [CMake] dependencies of cross compiliations

[Eric Noulard]

Le mar. 11 déc. 2018 à 14:18, Rolf Eike Beer  a écrit :

> Eric Noulard wrote:
>
> > When ones do cross compile for the host + one or several target a
> > lighter
> > "add_superbuild" API could be design. I'll try to think about it more
> > thoroughly and do some proposal. Ideally we shouldn't need to provide
> > many
> > parameters beside the toolchain and a way to specify "the host build".
>
> I guess putting the host-build location in the toolchain file could be
> one way
> to just get it done. In case one has multiple builds that should share
> one host
> build then just set an absolute location, and if you don't it will be
> below your
> normal build directory.
>

Yes that seems a reasonable way to do it.

There are just 2 things that scare me a bit off: we surely want a way to
> break
> that into smaller pieces so we can introduce it over multiple releases,
> maybe even
> as a tech-preview so we can break things if we see that we have not
> taken a bigger
> usecase in account, and I currently don't see the points to slice that
> up.
>

We could add new builtin command along with an enable_preview command that
would bring the currently in preview commands.
If you don't call enable_preview CMake will issue an error telling that the
command you are trying to are in "preview" if it's the case.
When enabling preview you'll get the "in-preview" command plus a warning
telling you that enabling preview brings you command/features that are not
guaranteed to be backward compatible.

Equipped with that we could incubate a feature and switch it from preview
to prime-time when we are confident about it.


> And we really, really want a
> .cmake_no_freaking_in_source_build_under_any_circumstances
> or however we gonna call it, and we need that first. There has been
> wasted enough time
> with in-source builds, missing cleanups and all the weird side effects
> in our industry
> for decades, and sadly CMake hasn't stopped that nonsense entirely.
> There are still
> projects out there that can only build this way because they do some
> assumptions on
> where to pick up files, but for something that will end up mixed
> cross/host build this
> will never under any circumstances going to work.
>

Yeah you are damn right, and guess what, I was convinced by that near a
decade ago from now
https://cmake.org/Bug/view.php?id=6672 !!

The old ticket got reloaded in the "new" tracker as
https://gitlab.kitware.com/cmake/cmake/issues/6672


> I wonder if we can't just add it as extra argument to
> cmake_minimum_required(), in a
> way that you _have_ to specify ALLOW_IN_SOURCE_BUILD explicitely if you
> require a version
> newer than say 3.14, so anyone that is not explicitely requesting this
> to work will
> automagically end up in a "clean" setup. Of course we need to make sure
> that no file is
> written by CMake until that line is parsed (or any other command is
> encountered). Or
> simply do something similar when using toolchain files, which CMake can
> detect before
> even start parsing the main CMakeLists.txt.
>

There is two problems here.

1) AFAIR (there is some discussion about that in the old ticket) as soon as
CMake is parsing CMakeLists.txt it creates the CMakeCache.txt and you want
to avoid polluting the source before that thus the proposal from Ben & Brad
to add the no-in-source enforcement in an extra file.

2) Changing the default behavior of not accepting in-source is good for me
but it is clearly backward incompatible. Unless I'm wrong there has not
been any such backward-incompatible change in CMake as of now.
I doubt this would be widely accepted. Or may be for CMake 4.


-- 
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:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] [CMake] dependencies of cross compiliations

[Eric Noulard]

Le dim. 9 déc. 2018 à 12:24, Craig Scott  a écrit :

> On Tue, Dec 4, 2018 at 6:56 PM Torsten Robitzki 
> wrote:
>
>> > Am 27.11.2018 um 19:55 schrieb Eric Noulard :
>> >
>> > My assumption are:
>> >  a) when you cross-compile your build is a "whole" and you shouldn't
>> have to setup some superbuild
>> >structure for building host tools ht_exe and another for target1
>> tool t1t_exe and another one for target2 tool t2t_exe.
>> >
>> >  b) what you want is to build:
>> >  ht_exe for the host
>> >  possibly use ht_exe during the build to generate some [source] file
>> >  t1t_exe for the [cross]target1
>> >  t2t_exe for the [cross]target2
>> >
>> >  c)  you seldomly compile the same source for the host AND the target,
>> but it may happen.
>>
>> In case, you are doing unit tests, it’s normal to have the same code
>> running in a test on the host platform and in the final binary on the
>> target.
>>
>> I think, having more than 1 target platform becomes more and more normal
>> as it becomes more usual to have multiple microcontrollers in a project.
>>
>
Yes that's why I thought it was worth going further than host + target, but
host + tgt1 + tg2 + 


>
>> Previously, I have encoded this in the build type. So instead of just
>> having Debug and Release, I had HOST_Debug, HOST_Release NRF51_Debug,
>> NRF51_Release, STM8_Debug, STM8_Release and so on. It doesn’t annoy me very
>> much, that I have to run CMake 3 times to get all the binaries for a
>> release build. The problem that I have, are dependencies between this
>> builds. If I write a tool that (for example) generates source files for one
>> of the target platforms, the build for the host platform must run before
>> the build for that target platform. And when I make changes to that tool, I
>> want the build to regenerate the generated source files.
>>
>> Keeping track of this dependencies to solve this kind of ordering issues
>> and to allow minimum rebuilds, is the main purpose of any build system. To
>> solve this with CMake, I think we need a way to define the dependencies
>> between build types (in the example above, from the generator from the host
>> build to the generated source file in one of the target builds) and CMake
>> needs to know the build directory for all build types (not only the
>> current).
>>
>
> Perhaps a superbuild would be the cleanest approach here? The host tools
> would be one subproject and the cross-compile builds would depend on the
> host tools' build. You could then choose to build everything via the top
> level superbuild or just work on one of the subprojects if that's all you
> needed once the initial tools build had been done. You could even set up as
> many different sub-projects for the different architectures as needed.
> Packaging would require a little more work, but it shouldn't be
> prohibitively so.
>

I guess the tough part is to find a [light] way to specify dependencies
between host target build and the various target builds.


> Another alternative is the approach described in this stackoverflow
> article
> <https://stackoverflow.com/questions/36084785/building-a-tool-immediately-so-it-can-be-used-later-in-same-cmake-run>
> which performs the host tools build off to the side in a secondary build
> during configure. This works well when the host tools don't change much (we
> use it extensively at work with very large, complex hierarchical projects).
> It wouldn't help though if you need to build more than one cross-compiled
> architecture.
>
> > The wish-season is coming up, so that's sort of what I would like to
>> > have. Now it's your turn. No bikeshedding please, only deliveries ;)
>>
>> How about ``add_dependencies()`` allowing me to define dependencies
>> between different build types? :-)
>>
>
> A superbuild would already give you the equivalent capability.
>

Not as easy as it seems right?
I bet you know it well as you listed the dependencies shortcoming of adding
dependencies for External_ProjectAdd in your book (§27.1.4).

-- 
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:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] [CMake] dependencies of cross compiliations

[Eric Noulard]

Le mer. 28 nov. 2018 à 21:03, Rolf Eike Beer  a écrit :

> Am Dienstag, 27. November 2018, 19:55:56 CET schrieb Eric Noulard:
>
> > I think that most of the time specifying the toolchain on the command
> line
> > drives you to some superbuild structure.
>
> Which is not bad by itself, but I would like to see that CMake can provide
> things that avoid people reinventing the boilerplate code, and probably
> getting them wrong at least 80% of the time. Like they would do with
> dependencies and other things if they would write their Makefiles by hand
> instead of using CMake, just one level higher.
>

I do totally agree with this.
Superbuild is nice but you have to write a lot of boilerplate CMake code
*each time* you want to do it.
May be a good path would be to have a "builtin" support for superbuild in
CMake which
would make its usage lighter than the usual ExternalProject_Add.

When ones do cross compile for the host + one or several target a lighter
"add_superbuild"
API could be design. I'll try to think about it more thoroughly and do some
proposal.
Ideally we shouldn't need to provide many parameters beside the toolchain
and a way
to specify "the host build".


>
> > > The wish-season is coming up, so that's sort of what I would like to
> > > have. Now it's your turn. No bikeshedding please, only deliveries ;)
> >
> > I wish an integrated multi-target cross building support in CMake with
> > little or no flow-control scripting command in the CMakeLists.txt.
>
> That would mean introducing HOST and TARGET flags to every find_* call,
> I'm
> not sure if that is cleaner than explicit if()'s. But I'm not
> fundamentally
> opposed to it, I'm just not sure it's worth the effort.
>

Sure, I agree too.
May not be worth, let's dig the "light superbuild" approach a little
further first.

-- 
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:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] [CMake] dependencies of cross compiliations

[Eric Noulard]

Le mar. 27 nov. 2018 à 11:28, Rolf Eike Beer  a écrit :

> Am 2018-11-09 10:04, schrieb Torsten Robitzki:
> > Hi,
> > I hope this question was not asked before. I work in the embedded
> > field and there it is usually to have at least two different build
> > platforms. The Host platform, where unit tests are build (and where
> > CMake is running) and an embedded Target platform, where targets are
> > build with a cross compiler. Sometimes such a system comes with
> > self-written tools that are build and run on the Host platform to
> > build a target for the embedded Target platform (adding meta data to a
> > binary to be used by a bootloader for example).
> >
> > Usually I have two different build folders, one for the Host platform
> > and one for the Target platform, using different calls to cmake to
> > choose from a set of tools and targets. But when using this approach,
> > it is necessary that the Host platform build ran before the Target
> > platform build, so that tools that are required for the Target
> > platform are build during the Host target build.
> >
> > One solution I’ve came up with, is to build the required tools during
> > the Target platform build, using an add_custom_target() to invoke the
> > Target compiler directly. This works fine, as long as the tools are
> > basically build just out of a couple of files.
> >
> > What would be the „CMake-Way“ to add the tools (that have to be build
> > on the Target platform) as dependency to targets that have to be build
> > for the Target (cross compile) platform?
>
> TL;DR: there is not "good" way yet. But there should be one.
>
>
I do agree with that quote I was quite surprised (a long time ago) that
CMake did not support cross-compiling.
Back then I was using recursive hand-written makefiles for cross-compiling.
When I wanted to build
the whole thing I only had to hit "make" and wait.

Moreover I think CMake cross-compiling support was biased by the fact CMake
wasn't designed for that initially.
Please don't take my remark as bare criticism I am using CMake for a long
time now, I do like CMake very much
and I was pleased to see the cross-compiling support coming.

However from my point of view and my cross-compiling experience when you
cross-compile you have:

1) the host compiler which is used to compile "host tools"
2) the target compiler (may be several of them) to "cross-compile"

My assumption are:
 a) when you cross-compile your build is a "whole" and you shouldn't have
to setup some superbuild
   structure for building host tools ht_exe and another for target1 tool
t1t_exe and another one for target2 tool t2t_exe.

 b) what you want is to build:
 ht_exe for the host
 possibly use ht_exe during the build to generate some [source] file
 t1t_exe for the [cross]target1
 t2t_exe for the [cross]target2

 c)  you seldomly compile the same source for the host AND the target, but
it may happen.

And you want to build all that stuff with a single configure+build command
AND take advantage
of fast and efficient parallel build for the **whole build**. I don't want
to

cd /build/for/host
ninja
cd /build/for/target1
ninja
etc...



>  Helpful would be a special
> variable for CMAKE_INSTALL_PREFIX as this needs a bit of attention (and
> a non-sysroot thing prefix in the toolchain file). Confused? Granted,
> here is an example:
>
> if (CMAKE_CROSSCOMPILING)
>  set(HOST_INSTALL_DIR "/some/where")
>  add_host_build(. host HOST_INSTALL_DIR)
> endif ()
> add_executable(magic magic.cpp)
> install(TARGETS magic DESTINATION bin) # installs both the host and the
> target tool!
> add_custom_command(OUTPUT ${CMAKE_CURRENT_BUILD_DIR}/foo.cpp COMMAND
> magic) # will call the host build
> if (NOT CMAKE_HOST_BUILD)
>  add_executable(foo ${CMAKE_CURRENT_BUILD_DIR}/foo.cpp)
>  install(TARGETS foo DESTINATION bin)
> endif ()
>

I get your point but I think we may try a more declarative way.

add_executable(magic magic.cpp)
install(TARGETS magic DESTINATION bin)
add_custom_command(OUTPUT ${CMAKE_CURRENT_BUILD_DIR}/foo.cpp COMMAND magic)
add_executable(foo ${CMAKE_CURRENT_BUILD_DIR}/foo.cpp)
install(TARGETS foo DESTINATION bin)

set_target_properties(magic PROPERTIES BUILD_TARGET "host;cross_target1")
set_target_properties(foo PROPERTIES BUILD_TARGET "cross_target1")

after that we know that `magic` is to be built both for "host" and
"cross_target1" whereas
`foo` is only for "cross_target1".

before that we may have to "declaratively" define what is cross_target1
(and may be cross_target2) with something like:

enable_cross_target(NAME cross_target1 TOOLCHAIN ${CMAKE_CURRENT_SOURCE
_DIR}/cmake/target1-toolchain.cmake)
enable_cross_target(NAME cross_target2 TOOLCHAIN ${CMAKE_CURRENT_SOURCE
_DIR}/cmake/target2-toolchain.cmake)
and assume "host" builtin target is the one coming from the command line.

each define_cross_target(..) will create a separate subdir in the build
tree (much like CMAKE_CFG_INTDIR is working for multi-config 

Re: [cmake-developers] ENV{SOURCE_DATE_EPOCH}

[Eric Noulard]

Le mar. 20 nov. 2018 à 22:40, Oleh Kravchenko  a écrit :

> 20.11.18 23:29, Brad King wrote:
> > SOURCE_DATE_EPOCH was created for use by packagers where tools
> > already wrap the build.  By making it an environment variable
> > packagers could jump through any number of build system layers
> > with no patching.
>
> That's makes me confused, because CMake has CPack.
> And with CPack process looks like:
> - `cmake && make package`
> So there are no any packagers tools, all work done with CMake.
>

The package tool here is CPack.
You consider CMake and CPack as monolithic software they were not designed
this way (and I personally find it nice to be so).

CMake and CPack (or CTest) may work together but they may well be used
independently.
Moreover they do not run at the same time, have a look at the figure here:
https://github.com/dev-cafe/cmake-cookbook/blob/master/figures/cmake-times/cmake-times.jpg

And you may see that setting environment var at configure time is
relatively far away from packaging time.

All that saif you are right CPack may honor SOURCE_DATE_EPOCH, and CMake
"may" forward the usage
of SOURCE_DATE_EPOCH from configuration time down to CPack time.

At least one CPack generator (the DEB one) recently honor SOURCE_DATE_EPOCH
https://gitlab.kitware.com/cmake/cmake/commit/548ac51d8ea319c65abefa0a771636893c45014c


If you use a
https://cmake.org/cmake/help/v3.12/module/CPack.html#variable:CPACK_PROJECT_CONFIG_FILE
for your project
you may easily set the SOURCE_DATE_EPOCH env var at CPack time, i.e. when
CPack runs.



> > Build systems configure compilers with command-line flags, not
> > environment variables.  If you want to do this from within the
> > build system then GCC could be taught a new option for that.
>

Apparently gcc team decided to use env var for that:
https://gcc.gnu.org/onlinedocs/cpp/Environment-Variables.html
see associated discussion (I did not read it all):
https://gcc.gnu.org/ml/gcc-patches/2015-06/msg02210.html

llvm/clang discussion on this does not seem to be closed:
https://reviews.llvm.org/D23934


> >
> > You could try hacking it with `CMAKE__COMPILER_LAUNCHER`:
> >
> >
> https://cmake.org/cmake/help/v3.13/variable/CMAKE_LANG_COMPILER_LAUNCHER.html
> >
> > e.g. -DCMAKE_C_COMPILER_LAUNCHER='env;SOURCE_DATE_EPOCH=1' or
> >
> > ```cmake
> > set(CMAKE_C_COMPILER_LAUNCHER env SOURCE_DATE_EPOCH=1)
> > ```
>
> Thank you, I will try that.
>

AFAIU this should already work with gcc.

I discovered https://reproducible-builds.org/, while reading your question.
The goal is nice, and I think CMake/CPack should support that for
compiler/[package] build tools that support it.

I won't have time to work on patches for that but I'll certainly take time
to read/test one if someone is working on it.

-- 
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:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] Preferred case for macro names?

[Eric Noulard]

Le mar. 13 nov. 2018 à 10:41, Marc CHEVRIER  a
écrit :

> I agree as well that trying to distinguish macros from functions is not a
> good idea because functions can act in the same way as macros (i.e.
> changing calling environment) but with a better control over environment
> changes (changes are done explicitly by using 'set(... PARENT_SCOPE)').
>
> so also +1 for lower case for every function, macro or builtin. And good
> point to standardize  macro or function OPTION to UPPERCASE.
>
> Now, for variables, the problem is a bit different because they are case
> sensitive: 'set(my_var ...)' and 'set (MY_VAR ...)' will create two
> different variables.
>

Yes damn right.


> My personal tendency is to use lower case for local variables and upper
> case for global variables. May be we can normalize variables to upper case
> regarding global variables used by CMake itself (which is globally the
> current rule).
>

Having a convention for local is nice and I tend to prefix with _ (single
or double) variables that should be local.
lowercasing locals is fine too, however I think that enforcing casing on
"user-defined" variable may not be desirable, concerning CMAKE_ CTEST_ and
CPACK_
I guess they already are all UPPERCASE so we may stick with this as a
convention?

A small quote to the cmake-format (
https://github.com/cheshirekow/cmake_format) tool which is trying to
beautify CMakeLists.txt, I'm not using it on complex projects
because it still has some issues but I find it otherwise useful.


-- 
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:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] Preferred case for macro names?

[Eric Noulard]

Le mar. 13 nov. 2018 à 00:21, Craig Scott  a
écrit :

>
>
> On Tue, Nov 13, 2018 at 9:51 AM Joachim Wuttke 
> wrote:
>
>> My understanding was that prevalent usage in modern CMake
>> is all lowercase for function names, all uppercase for
>> macro names. In this sense, I submitted a number of merge
>> requests where function and macro names are normalized, and
>> in
>>https://gitlab.kitware.com/cmake/cmake/merge_requests/2607
>> I suggest an explicit recommendation in the macro and
>> function doc pages.
>>
>> Now I am learning from Craig Scott that the more recent
>> convention is actually all lowercase for macros as well
>> as for functions.
>>
>
> To be clear, my understanding is that in the past (many years ago),
> uppercase tended to be common, but I don't see that used much these days
> for functions, macros or built-in commands. The general sentiment seems to
> be that uppercase tends to be a bit "shouty" now. I'm suggesting that if
> we're going to bring some consistency to the docs, I propose that we just
> go with lowercase everywhere (functions, macros, built-in commands and
> examples).
>
> 
> Regarding the finer points of macros versus functions versus built-in
> commands and establishing a convention, it's actually a bit difficult to
> draw a hard line in behaviour across all three. Consider commands like
> find_package() and project(). These are built-in commands, but they behave
> like a macros in that they add variables to the calling scope (yes,
> functions can do that too, but the primary reason to use macros is to
> inject variables into the calling scope). Most built-in commands act more
> like functions and do not modify the calling scope. Trying to decide
> whether built-in commands act like macros and which do not and making them
> upper or lowercase based on that is unlikely to be a distinction that most
> users would make, so a mix of upper and lowercase for built-in commands
> would be unexpected. A consequence of this is that having macros and
> functions with differing case conventions would seem to create a potential
> inconsistency with whatever convention is used for built-in commands. The
> only way to really have consistency here would seem to be just use the one
> case convention, for which lowercase seems to be the logical and
> increasingly prevalent choice.
> 
>

I would add that sometimes useful macro/function may become builtin
See example for include_guard in
https://github.com/dev-cafe/cmake-cookbook/blob/master/chapter-07/recipe-06/example/CMakeLists.txt

So differentiating macro/function/builtin by their case does not seems a
good option to me.
My personal opinion though.

+1 for lower case for every function, macro or builtin.
macro or function OPTION are UPPERCASE
properties are UPPERCASE as well
and I personnally tend to define CMake VARIABLES as uppercase too.


-- 
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:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] option to prevent in-source builds

[Eric Noulard]

Just a small remark to say this request of "builtin" way to forbid
in-source is quite old:
https://gitlab.kitware.com/cmake/cmake/issues/6672
which find its origin in:
https://cmake.org/Bug/view.php?id=6672

I don't know if the note from that initial discussion are valid nowadays
but the fact that:
"Code in CMakeLists.txt is not even executed until after the cache is
initialized so there would have to be some other way to indicate in the
source tree that it should not be built in-source."
and the fact that
"The cache is initialized before the procedural steps start to run. With
cmake-gui or the cmake command-line "-D" option it is even possible to
store entries in the cache before CMake even parses CMakeLists.txt"
almost implies that this should be done outside CMakeLists.txt

That said, I think that
I would rather have some obviously visible and fixed place like
CMakeInit.json that should be located in the very same directory as the
concerned CMakeLists.txt rather than some list of possible places (cmake/,
cmake/init, .cmake, etc...). The exact path to CMakeInit.json could be
overwritten by some new command line option, like --init-file if for some
reason we want
a configurable place (may be used in various CI scripts occasion).
This file could hold more options than "just forbid in-source" it could
indicate a default generator (which may be different from the usual default
generator on the concerned platform),
some a toolchain. It's usage would be different than the initial cache
precisely because it could work before cache is created.


Le ven. 9 nov. 2018 à 17:03, Ben Boeckel  a écrit :

> On Fri, Nov 09, 2018 at 07:28:54 -0500, Taylor Holberton wrote:
> > A lot of projects that use CMake already have a `./cmake` directory, I
> > would think `./cmake/init.json` would fit nicer as opposed to the hidden
> > directory. I'm not a fan of hidden directories in software projects
> anyway.
>
> There are also `./CMake` directories. HDF5 uses `./config/cmake`. I
> think just claiming a "hidden" directory with exact casing is better.
>
> --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:
> https://cmake.org/mailman/listinfo/cmake-developers
>


-- 
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:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] How to handle dependencies of protobuf files ?

[Eric Noulard]

Le mer. 30 mai 2018 à 15:12, Brad King  a écrit :

> On 05/29/2018 04:00 PM, Alexander Neundorf wrote:
> >> In order to handle implicit dependencies like that implied by
> >>
> >> import "MyBase.proto";
> >>
> >> then they would somehow need to be extracted from source content.
> >
> > Would that have to be implemented similar to the C dependency scanning ?
>
> Yes, but even better would be if we can ask protoc to print the
> dependencies
> out for us so we don't have to parse the sources ourselves.
>

protoc can already do something like that but it spits out a makefile
includable file.

see --dependency_out=FILE option.
Write a dependency output file in the format
  expected by make. This writes the transitive
  set of input file paths to FILE

moreover the generated makefile depends on the langage generator used
(--cpp_out, --java_out, --python_out, ...) because dependencies are
expressed between proto and
generated source files.

May be it would be possible to write a protoc "plugin"
https://www.expobrain.net/2015/09/13/create-a-plugin-for-google-protocol-buffer/

which would spit out easy to digest dep spec for CMake.

Unfortunately I'm not volunteering :-( just giving some idea.


> > so the cheap solution would be to add an argument to
> PROTOBUF_GENERATE_CPP()
> > to list proto-files these proto-files depend on
>
> Yes, that would be a good intermediate solution.
>
> -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:
> https://cmake.org/mailman/listinfo/cmake-developers
>


-- 
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:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] Undocumented command line flags (-H, -B) why?

[Eric Noulard]

Thank you very much for the explanation.


2018-01-16 14:46 GMT+01:00 Ben Boeckel <ben.boec...@kitware.com>:

> On Tue, Jan 16, 2018 at 13:10:07 +0100, Eric Noulard wrote:
> > I came accross -H and -B undocumented command line flags for cmake:
> > https://stackoverflow.com/questions/24460486/cmake-
> build-type-not-being-used-in-cmakelists-txt/24470998#24470998
> >
> > Is there any reason to keep those undocumented?
>
> They're internal and not meant for use outside of CMake itself. There
> have been threads on this before. Here's one with a patch to document it
> that was rejected as-is:
>
> https://www.mail-archive.com/cmake-developers@cmake.org/msg16693.html
>
> For those who want to submit a patch, there's a TODO list here:
>
> https://www.mail-archive.com/cmake-developers@cmake.org/msg16720.html
>
> --Ben
>



-- 
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:
https://cmake.org/mailman/listinfo/cmake-developers

[cmake-developers] Undocumented command line flags (-H, -B) why?

[Eric Noulard]

Hi there,

I came accross -H and -B undocumented command line flags for cmake:
https://stackoverflow.com/questions/24460486/cmake-build-type-not-being-used-in-cmakelists-txt/24470998#24470998

Is there any reason to keep those undocumented?

-- 
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:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] Optionally disabling static lib dependencies with COMPILE_DEPENDS

[Eric Noulard]

2018-01-04 10:48 GMT+01:00 Craig Scott :

>
>
> On Thu, Jan 4, 2018 at 8:27 AM, John Wordsworth 
> wrote:
>
>> I have recently been reviewing ways to improve build times for our
>> project, which is comprised of a number of static libraries. I stumbled
>> across this post on the CMake tracker from 2012/13 (
>> https://cmake.org/Bug/view.php?id=13799). It suggests adding a
>> COMPILE_DEPENDS target property to to explicitly set dependencies for
>> STATIC libraries instead of always using all linked libraries as
>> build-order dependencies.
>>
>> Having done a draft implementation in a local CMake repository it has
>> shaved off  20% of our 120s build time. I expect the savings to be much
>> more dramatic when I test with Incredibuild (approximately 50% based on
>> tests done previously from just deleting dependencies manually in Visual
>> Studio).
>>
>
You said you tested with Incredibuild but with what kind of configuration?
AFAIK Incredibuild takes its power from distributing the build? So does
your CMake test uses something that distribute the build too ?


>
>> I don’t really want to refactor our code to use “OBJECT” libraries as the
>> inability to link with other targets means that propagating compile options
>> / include directories etc down the chain of linked libs becomes painful.
>> This method allows me to switch between static and shared libs using a
>> config option and none of my CMake scripts need to change.
>>
>
> There's a couple more choices here. If your project consists of lots of
> small (static) libraries, consider whether you can combine some of them to
> result in a smaller number of larger libraries. This isn't always a gain,
> but in terms of ability to compile sources in parallel, it will often lead
> to more efficient builds. You just need to be careful you don't end up with
> so many objects being combined into one library that you start to hit max
> open file limits during linking/archiving (something I've hit on multiple
> platforms lately, so it's not just a hypothetical example). Use of
> target_sources() can be quite helpful if you want to try out this path (you
> may find this article
> 
> helpful).
>
> Another choice is to go in the opposite direction and take advantage of
> the optimisation made for the Ninja generator (if that's a choice open to
> you) that was introduced in CMake 3.9.0
>  where if no
> custom commands exist on a target A, then compilation steps of another
> target B linking to A are allowed to proceed without waiting for A's link
> step to complete. Only B's link step will depend on A's link step. In your
> project, if you have custom commands, see if you can split up that target
> into just those sources that need the results of the custom command and
> another target that doesn't. The latter will then be able to compile
> earlier, so fewer sources have to wait for earlier linking steps. This
> might be hard to do, it really depends on how your project is structured.
>

I fully agree with Craig here. We use CMake + Ninja and we get really
efficient parallel build (on 10+ cores machines).
This is on Linux though but it seems MS is putting effort to get CMake +
ninja build work with Visual Studio:
https://blogs.msdn.microsoft.com/vcblog/2017/05/10/cmake-support-in-visual-studio-whats-new-in-2017-15-3-update/

Another way to improve your build may be to review your dependency graph
carefully. You can use cmake --grahviz options to dump the graph and see
whether you can cut
some dependencies due to transitivity of dependency. I have seen many
projects with "overspecified deps". I think this impair build time when
using a lot of static libs because in that case you may get
poor performance link time. Namelly if you have many unit tests linking to
too many static libs because of overspecified deps.

That said you did not specify whether if the 120s build time is only for
the library or if this is a "global" build time which includes linking
somes executables and possible unit tests programs.

Note that even if this is not the case having a "big-picture" look at the
dependency build graph generated by CMake may be insightful.
Note that with CMake 3.10 you can now see difference between PUBLIC,
PRIVATE and INTERFACE deps:
https://cmake.org/cmake/help/v3.10/release/3.10.html



>
> Both of the above choices allow you to retain the automatic propagation of
> compile options, include directories, etc. and to switch between
> shared/static easily, but the latter is specific to the Ninja generator and
> may not be an acceptable change for you.
>
>
>>
>> Anyway, I was wondering whether there was any interest in me pushing my
>> solution back to Git / submitting a Pull request so that it might be merged
>> in at some point. If there is - any advice on any gotchas I might watch 

[cmake-developers] Dependency graph in server mode?

[Eric Noulard]

Hi there,

Is it possible to get the dependency graph one can get with the --graphviz
option when running in server mode.

>From my understanding the current "codeModel" message does not contain such
information. Am I right?

If I wanted to add the dependency information would it be better to create
a new server mode
message or put that into current "codeModel"?


-- 
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] Java language support regression (compared with 3.7.x and 3.8.x) for 3.9.0

[Eric Noulard]

2017-07-22 0:23 GMT+02:00 Alan W. Irwin :

> I have built CMake-3.9.0 on my Linux (Debian Jessie) platform using
> the bootstrap method I have always successfully used for other CMake
> versions (including 3.7.2).
>
> For a complex project (PLplot) which uses swig_add_module and
> swig_link_libraries to implement our Java binding, I get the following
> error message at the end of that CMake-3.9.0 output.
>
> -- Configuring done
> CMake Error: Error required internal CMake variable not set, cmake may
> not be built correctly.
> Missing variable is:
> CMAKE_Java_CREATE_SHARED_MODULE
> -- Generating done
> -- Build files have been written to:
> /home/software/plplot/HEAD/build_dir
>
> I don't get this error message for CMake-3.7.2.
>
> Using find and xargs -0 grep I have looked in both 3.7.2 and 3.9.0
> source code for any mention of CMAKE_Java_CREATE_SHARED_MODULE, and it
> just does not exist.
>
> By the way, I have tried the following simple project.
>
> cmake_minimum_required(VERSION 3.6.2 FATAL_ERROR)
> project(test_java NONE)
> enable_language(Java)
> message(STATUS "CMAKE_Java_CREATE_SHARED_MODULE =
> ${CMAKE_Java_CREATE_SHARED_MODULE}")
>

I'm curious with that.
I do currently use UseJava.cmake module
https://cmake.org/cmake/help/v3.7/module/UseJava.html
for building some java bits in a globally C++ project.

I never tried  enable_language(Java)
what is the status of Java support as a primary language?

I tried to find informations about that in the doc and mailing list but
didn't find much.

Could someone please point me to the appropriate place concerning this?


-- 
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 a new henerator for CMake

[Eric Noulard]

Hi Renato,

Did you start to work on a Bazel generator for CMake?
If not do you still plan to do it?

Eric

2017-03-17 11:51 GMT+01:00 Renato Utsch :

> Ooh good to know, I'll take a look at how you're doing that.
>
> No, the build system is Bazel.
>
> On Fri, Mar 17, 2017, 04:58 Charles Huet  wrote:
>
>> Hi,
>>
>>
>> is this buildsystem by any chance FastBuild ?
>> Because if so there is an effort (I'd like to say ongoing, but it's been
>> on hold since the release of 9.7) to implement one here:
>> https://github.com/packadal/CMake/tree/fastbuild-master
>>
>> Otherwise I guess it can serve as another example, as far as I know there
>> is no documentation on how to implement a generator from scratch.
>>
>> Good luck !
>>
>> Le ven. 17 mars 2017 à 02:39, Renato Utsch  a
>> écrit :
>>
>> Hello,
>>
>> Is there documentation somewhere on how to add a new generator to CMake?
>> There's a build system I really want CMake to support, and I'd like to
>> contribute to make that happen.
>>
>> How difficult / how much code is involved in writing a new generator? The
>> build system has nothing to do with makefiles.
>>
>> Thank.
>>
>> --
>>
>> 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
>>
>>
> --
>
> 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
>



-- 
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] Does JOB_POOL_[COMPILE|LINK] work with custom_target?

[Eric Noulard]

Hi all,
No answer whatsoever on this?

Initial contributor of Ninja job pool appears to be Peter Kümmel:
commit 7605e37aabae2678e5696a75e84aced2e84f9037
Author: Peter Kümmel <syntheti...@gmx.net>
Date:   Sat Nov 23 10:49:36 2013 +0100


I'd like to be able assign some custom targets to a ninja job pool.
If I were to implement the feature would it be acceptable upstream ?

Eric

2017-05-05 16:16 GMT+02:00 Eric Noulard <eric.noul...@gmail.com>:

> Hi all,
>
> We have a bunch of custom_target and a subset of them should be run in
> sequence.
> So we tried to define:
>
> set_property(GLOBAL PROPERTY JOB_POOLS exclusive=1)
>
> and then:
>
> set_property(TARGET my_custom_target PROPERTY JOB_POOL_COMPILE exclusive)
> set_property(TARGET my_custom_target PROPERTY JOB_POOL_LINK exclusive)
>
>
> This does not seem to reach build.ninja ?
>
> The new pool is defined but the concerned custom targets are never
> assigned to the pool?
>
> May custom target be assigned to a ninja pool?
> If so how can we do that?
> --
> Eric
>



-- 
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 a new henerator for CMake

[Eric Noulard]

2017-03-17 11:51 GMT+01:00 Renato Utsch :

> Ooh good to know, I'll take a look at how you're doing that.
>
> No, the build system is Bazel.
>

I'd be interested in a Bazel generator as well.
I may help or review it depending on my spare time.

Eric




> On Fri, Mar 17, 2017, 04:58 Charles Huet  wrote:
>
>> Hi,
>>
>>
>> is this buildsystem by any chance FastBuild ?
>> Because if so there is an effort (I'd like to say ongoing, but it's been
>> on hold since the release of 9.7) to implement one here:
>> https://github.com/packadal/CMake/tree/fastbuild-master
>>
>> Otherwise I guess it can serve as another example, as far as I know there
>> is no documentation on how to implement a generator from scratch.
>>
>> Good luck !
>>
>> Le ven. 17 mars 2017 à 02:39, Renato Utsch  a
>> écrit :
>>
>> Hello,
>>
>> Is there documentation somewhere on how to add a new generator to CMake?
>> There's a build system I really want CMake to support, and I'd like to
>> contribute to make that happen.
>>
>> How difficult / how much code is involved in writing a new generator? The
>> build system has nothing to do with makefiles.
>>
>> Thank.
>>
>> --
>>
>> 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
>>
>>
> --
>
> 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
>



-- 
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] Update bash completion scripts

[Eric Noulard]

2016-06-10 15:56 GMT+02:00 Brad King <brad.k...@kitware.com>:

> On 06/10/2016 09:31 AM, Eric Noulard wrote:
> > Here comes an update of the bash completion scripts.
> > All of them now handle the same set of --help-xxx options
> > the handling of --help-manual has been added.
>
> Thanks, applied:
>
>  bash-completion: Add cmake --help-manual
>  https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f67afbdc
>
>  bash-completion: Add ctest --help-{manual,module,policy,property,variable}
>  https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c8178a77
>
>  bash-completion: Add cpack --help-{manual,module,policy,property}
>  https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=eacb75de
>
> > + --help-policy)
> > +COMPREPLY=( $( compgen -W '$( ctest --help-policies
> 2>/dev/null |
> > +grep "^  CMP" 2>/dev/null )' -- "$cur" ) )
> > +return
> > +;;
>
> Does this actually work?  IIRC older CMake versions did not
> have `--help-policy-list` so the `--help-policies` hack was
> used.  However, I don't know if the output format of the
> latter will be matched by the `grep` anymore.
>


You are right this part was obsolete.
To be honest I did not test the policy completion :-(


>
> If needed, please post a follow-up patch to fix policy completion
> for cmake, ctest, and cpack.
>

 Here you go.


-- 
Eric
From 003e68e5ef1e89036313b63bccd571a683894493 Mon Sep 17 00:00:00 2001
From: Eric NOULARD <eric.noul...@gmail.com>
Date: Fri, 10 Jun 2016 16:07:06 +0200
Subject: [PATCH 2/2] Update --help-policy completion with comtemporary cmake
 tools.

This was a leftover from previous patch.
---
 Auxiliary/bash-completion/cmake | 4 ++--
 Auxiliary/bash-completion/cpack | 4 ++--
 Auxiliary/bash-completion/ctest | 4 ++--
 3 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/Auxiliary/bash-completion/cmake b/Auxiliary/bash-completion/cmake
index 6997d47..6061129 100644
--- a/Auxiliary/bash-completion/cmake
+++ b/Auxiliary/bash-completion/cmake
@@ -132,8 +132,8 @@ _cmake()
 return
 ;;
  --help-policy)
-COMPREPLY=( $( compgen -W '$( cmake --help-policies 2>/dev/null |
-grep "^  CMP" 2>/dev/null )' -- "$cur" ) )
+COMPREPLY=( $( compgen -W '$( cmake --help-policy-list 2>/dev/null |
+grep -v "^cmake version " )' -- "$cur" ) )
 return
 ;;
  --help-property)
diff --git a/Auxiliary/bash-completion/cpack b/Auxiliary/bash-completion/cpack
index 8f14a72..be29528 100644
--- a/Auxiliary/bash-completion/cpack
+++ b/Auxiliary/bash-completion/cpack
@@ -59,8 +59,8 @@ _cpack()
 return
 ;;
  --help-policy)
-COMPREPLY=( $( compgen -W '$( cpack --help-policies 2>/dev/null |
-grep "^  CMP" 2>/dev/null )' -- "$cur" ) )
+COMPREPLY=( $( compgen -W '$( cpack --help-policy-list 2>/dev/null |
+grep -v "^cpack version " )' -- "$cur" ) )
 return
 ;;
  --help-property)
diff --git a/Auxiliary/bash-completion/ctest b/Auxiliary/bash-completion/ctest
index de8fde1..71f47ba 100644
--- a/Auxiliary/bash-completion/ctest
+++ b/Auxiliary/bash-completion/ctest
@@ -89,8 +89,8 @@ _ctest()
 return
 ;;
  --help-policy)
-COMPREPLY=( $( compgen -W '$( ctest --help-policies 2>/dev/null |
-grep "^  CMP" 2>/dev/null )' -- "$cur" ) )
+COMPREPLY=( $( compgen -W '$( ctest --help-policy-list 2>/dev/null |
+grep -v "^ctest version " )' -- "$cur" ) )
 return
 ;;
  --help-property)
-- 
2.8.1

-- 

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] Update bash completion scripts

[Eric Noulard]

Hi,

Here comes an update of the bash completion scripts.
All of them now handle the same set of --help-xxx options
the handling of --help-manual has been added.


-- 
Eric
From b201a66ab61643066294d554434829399371f733 Mon Sep 17 00:00:00 2001
From: Eric NOULARD <eric.noul...@gmail.com>
Date: Fri, 10 Jun 2016 15:28:05 +0200
Subject: [PATCH] Update bash completion scripts for cmake, cpack & ctest.

The modifications are:
- add the handling of --help-manual which was missing
- make the 3 commands handle the common set of completion for --help-.
---
 Auxiliary/bash-completion/cmake |  5 +
 Auxiliary/bash-completion/cpack | 22 +-
 Auxiliary/bash-completion/ctest | 26 ++
 3 files changed, 52 insertions(+), 1 deletion(-)

diff --git a/Auxiliary/bash-completion/cmake b/Auxiliary/bash-completion/cmake
index 557f243..6997d47 100644
--- a/Auxiliary/bash-completion/cmake
+++ b/Auxiliary/bash-completion/cmake
@@ -121,6 +121,11 @@ _cmake()
 grep -v "^cmake version " )' -- "$cur" ) )
 return
 ;;
+--help-manual)
+COMPREPLY=( $( compgen -W '$( cmake --help-manual-list 2>/dev/null|
+grep -v "^cmake version " | sed -e "s/([0-9])$//" )' -- "$cur" ) )
+return
+;;
 --help-module)
 COMPREPLY=( $( compgen -W '$( cmake --help-module-list 2>/dev/null|
 grep -v "^cmake version " )' -- "$cur" ) )
diff --git a/Auxiliary/bash-completion/cpack b/Auxiliary/bash-completion/cpack
index 05e0e93..8f14a72 100644
--- a/Auxiliary/bash-completion/cpack
+++ b/Auxiliary/bash-completion/cpack
@@ -48,7 +48,27 @@ _cpack()
 grep -v "^cpack version " )' -- "$cur" ) )
 return
 ;;
---help-variable)
+--help-manual)
+COMPREPLY=( $( compgen -W '$( cpack --help-manual-list 2>/dev/null|
+grep -v "^cpack version " | sed -e "s/([0-9])$//" )' -- "$cur" ) )
+return
+;;
+--help-module)
+COMPREPLY=( $( compgen -W '$( cpack --help-module-list 2>/dev/null|
+grep -v "^cpack version " )' -- "$cur" ) )
+return
+;;
+ --help-policy)
+COMPREPLY=( $( compgen -W '$( cpack --help-policies 2>/dev/null |
+grep "^  CMP" 2>/dev/null )' -- "$cur" ) )
+return
+;;
+ --help-property)
+COMPREPLY=( $( compgen -W '$( cpack --help-property-list \
+2>/dev/null | grep -v "^cpack version " )' -- "$cur" ) )
+return
+;;
+ --help-variable)
 COMPREPLY=( $( compgen -W '$( cpack --help-variable-list \
 2>/dev/null | grep -v "^cpack version " )' -- "$cur" ) )
 return
diff --git a/Auxiliary/bash-completion/ctest b/Auxiliary/bash-completion/ctest
index 387672a..de8fde1 100644
--- a/Auxiliary/bash-completion/ctest
+++ b/Auxiliary/bash-completion/ctest
@@ -72,11 +72,37 @@ _ctest()
 COMPREPLY=( $( compgen -W '0 1' -- "$cur" ) )
 return
 ;;
+
 --help-command)
 COMPREPLY=( $( compgen -W '$( ctest --help-command-list 2>/dev/null|
 grep -v "^ctest version " )' -- "$cur" ) )
 return
 ;;
+--help-manual)
+COMPREPLY=( $( compgen -W '$( ctest --help-manual-list 2>/dev/null|
+grep -v "^ctest version " | sed -e "s/([0-9])$//" )' -- "$cur" ) )
+return
+;;
+--help-module)
+COMPREPLY=( $( compgen -W '$( ctest --help-module-list 2>/dev/null|
+grep -v "^ctest version " )' -- "$cur" ) )
+return
+;;
+ --help-policy)
+COMPREPLY=( $( compgen -W '$( ctest --help-policies 2>/dev/null |
+grep "^  CMP" 2>/dev/null )' -- "$cur" ) )
+return
+;;
+ --help-property)
+COMPREPLY=( $( compgen -W '$( ctest --help-property-list \
+2>/dev/null | grep -v "^ctest version " )' -- "$cur" ) )
+return
+;;
+ --help-variable)
+COMPREPLY=( $( compgen -W '$( ctest --help-variable-list \
+2>/dev/null | grep -v "^ctest version " )' -- "$cur" ) )
+return
+;;
 esac
 
 if [[ "$cur" == -* ]]; then
-- 
2.8.1

-- 

Powered by www.kitware.com

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

K

Re: [cmake-developers] parallel install of different cmake versions

[Eric Noulard]

2015-12-14 15:42 GMT+01:00 Brad King :

> On 12/11/2015 06:42 PM, Orion Poplawski wrote:
> > For Fedora EPEL we often end up packaging newer versions of cmake as
> cmakeXY
> > (e.g. cmake34) that can be installed in parallel with the system cmake.
> This
> > is a fairly invasive process.  I'm attaching the current patch I'm
> working on
> > for this.  Is there any interest in cmake itself for supporting this
> kind of
> > thing?
>
> Not particularly.  That does look pretty invasive.
>
> Why not just install it to /usr/lib/cmake34 with normal names and symlink
> the versioned names?  E.g.
>
>  /usr/bin/cmake34 -> /usr/lib/cmake34/bin/cmake
>  /usr/bin/ctest34 -> /usr/lib/cmake34/bin/ctest
>


+1
Personnally when I installed several version of CMake I do install them
with a particular prefix and then I use update-alternatives(1) to install
proper symlinks to the specific location.

I switch from one version to another using update-alternatives(1).

This can certainly be used on Fedora/EPEL as well:
https://fedoraproject.org/wiki/Packaging:Alternatives


-- 
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] [CPackDeb] Configure Debian package name for components

[Eric Noulard]

2015-11-08 20:01 GMT+01:00 Markus Rickert :

> This is a long standing issue with related bugs:
>> http://public.kitware.com/Bug/view.php?id=12997
>> http://public.kitware.com/Bug/view.php?id=12574
>> http://public.kitware.com/Bug/view.php?id=11050
>> http://public.kitware.com/Bug/view.php?id=13015
>> http://public.kitware.com/Bug/view.php?id=15042
>>
>> which is shared (at least) by CPackRPM and CPackDeb
>>
>
> I'm aware of these bug reports, especially #12997, that focus on the file
> name of the generated .deb archive and would also be very interested in a
> solution for this.
>
> The package name inside the .deb archive however is the one used by the
> package manager and can be different from the file name. This would at
> least enable a match with upstream conventions and a proper substitution of
> upstream packages.
>

My too fast read of your patch and message make me think
that the issue was about the file name.

Now I understand.
-- 
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] [CPackDeb] Configure Debian package name for components

[Eric Noulard]

2015-11-08 13:34 GMT+01:00 Markus Rickert :

> Hi,
>
> it is currently not possible to modify the component part of the package
> name for Debian packages generated by CPack. For component-based packaging,
> the name is currently composed of
> "${CPACK_PACKAGE_NAME}${CPACK_DEB_PACKAGE_COMPONENT_PART_NAME}", where the
> latter is set to "-${CPACK_DEB_PACKAGE_COMPONENT}".
>


This is a long standing issue with related bugs:
http://public.kitware.com/Bug/view.php?id=12997
http://public.kitware.com/Bug/view.php?id=12574
http://public.kitware.com/Bug/view.php?id=11050
http://public.kitware.com/Bug/view.php?id=13015
http://public.kitware.com/Bug/view.php?id=15042

which is shared (at least) by CPackRPM and CPackDeb


>
> The use of CPACK_PACKAGE_NAME here does not match the behavior of
> non-component-based packaging, where CPACK_DEBIAN_PACKAGE_NAME can be
> defined.
>
> With CPACK_PACKAGE_NAME set to "foo" and CPACK_DEBIAN_PACKAGE_NAME set to
> "libfoo", a component "libraries" that gathers the libraries in a project
> then defaults to, e.g., "foo-libraries", rather than "libfoo" (without a
> component part) in the control file.
>
> These conventions can also differ between, e.g., Debian/Ubuntu and Fedora.
> The former would expect libraries in "libfoo", headers in "libfoo-dev", and
> documentation in "libfoo-doc", the latter however rather "foo"/"foo-devel"
> or "libfoo"/"libfoo-devel".
>
> I've included two possible patches for this. The first one adds a fully
> configurable component package name via
> CPACK_DEBIAN__PACKAGE_NAME, the latter only allows to set the
> part name appended to CPACK_DEBIAN_PACKAGE_NAME (with "-" still
> the default behavior).
>
> It would be great if one of those solutions could be integrated, as this
> enables better matching of CPack and upstream conventions. A similar patch
> could also be added to CPackRPM.
>
> Best regards,
>
> Markus Rickert
>
> --
>
> 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
>



-- 
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] [CPack] CPackDeb and fakeroot

[Eric Noulard]

2015-08-25 23:52 GMT+02:00 Raffi Enficiaud raffi.enfici...@mines-paris.org
:

 Le 25/08/15 16:48, Eric Noulard a écrit :

 I would suggest checking (in CPackDeb generator code) whether if CPack
 has been called in a fakerootED environment. This can be done by
 checking whether if FAKEROOTKEY env var is defined or not.
 If fakeroot is already in action then one should not call fakeroot again
 (whatever the fakerootED user is).


 Hmmm, unfortunately it does not work. This variable does not exist on the
 fakerooted shell. I think there is no good way to detect that we are in a
 fakerooted environment because their purpose is to mimic the commands as if
 the real root user is entering them (and introspection should not be
 possible by design).


You are right the design of fakeroot is to mimic...

I tested it using

 erk@capitaine:tmp$ fakeroot bash
root@capitaine:tmp# echo $FAKEROOTKEY
489393277

but it does not seem to be set when fakerooting a simple command (outside a
shell).


 I see two technical solutions:
 - either using the system tar: this would not work in the case of cross
 compilation (and in some circumstances only) but would work in the other
 case. I believe that all the debian packaging tools are just using the
 system provided tar, so this should closely mimic the debian-packaging
 machinery better,


Cross-compiling is one thing, cross packaging is another.
I think trying to cross-package is a very hard task (unless you simply
create a bare archive (tar, zip, etc...)

- or using a CPACK variable to avoid having fakeroot executed


seems awkward to disable black magic with another black magic spell.



 I see several workarounds/hacks:
 - executing with fakeroot in cpack first and in case of failure falling
 back to run tar without fakeroot
 - detect if the current user is root already


Detecting if user is already root doesn't seems to be such a big hack
it should even be robust as well and should be a 2 line modfication
in CPackDeb.cmake protecting it even detecting FAKEROOT alltogether.


-- 
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] [CPack] CPackDeb and fakeroot

[Eric Noulard]

2015-08-26 0:56 GMT+02:00 Raffi Enficiaud raffi.enfici...@mines-paris.org:

[...]


 I see several workarounds/hacks:
 - executing with fakeroot in cpack first and in case of failure
 falling back to run tar without fakeroot
 - detect if the current user is root already


 Detecting if user is already root doesn't seems to be such a big hack
 it should even be robust as well and should be a 2 line modfication
 in CPackDeb.cmake protecting it even detecting FAKEROOT alltogether.


 Right, but I am more concerned about the proper way of doing it and not
 the difficulty. From all this discussion, using fakeroot directly does not
 look to me as the right solution for having root in the tar, in the first
 place. So if we are also able to get rid of the fakeroot machinery in
 cpack, maybe it would be a better solution.


I agree, then the question is should every deb package built by CPack being
owned by root?

Currently people making deb with CPack without having fakeroot installed
get their
package with current user owning. i.e. fakeroot is not ALWAYS used.

Now if you find a way to set root ownership in archive created by CPackDeb
then every deb package
will have those right.

My opinion (from the various bug report related to deb ownership) is that
is OK since creating a deb including
whatever non-root user in it is a mistake.

So the proper way to go may  be to use libarchive directly in CPackDeb to
create tar in order to better control ownership of the created bits.

This is definitely more work, but this looks the proper way to me.

-- 
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] dry-run support

[Eric Noulard]

2015-07-01 10:34 GMT+02:00 Honggyu Kim hong.gyu@lge.com:

 Hi all,

 I would like to see the exact command execution list when I build using
 cmake.
 Make has an option --dry-run as many of you already know:

 $ make --help
 -n, --just-print, --dry-run, --recon
   Don't actually run any commands; just print
 them.

 Can anyone please let me know if there's a way to do dry-run in cmake.
 I appreciate all your comments.


There is one big noticeable difference between make and cmake.
CMake does not build software it creates build system that will be used
to build.

So dry-running CMake will not give you exact command execution for
building.
The other main difference is that CMake has control statements-(option,
find_package, if-else, ...)
so that action/command executed during CMake run may heavily depend on the
**effective execution** (e.g. find_package) of a previous line of  the
CMake script.

So I my idea is that dry-run is not as useful for CMake as it is for make
(or ninja -n or other
build tool dry run mode).

What you already have with CMake is the --trace option which can be very
useful
to understand what happen at CMake time.

Then it may also be useful to dry-run the resulting build files produced by
CMake.
i.e.:

make --dry-run
ninja -n -v
...

-- 
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] Generator Expressions in CPack (Module) variables

[Eric Noulard]

2015-04-28 10:57 GMT+02:00 Gregor Jasny gja...@googlemail.com:

 Hello Nils,

 thank you for the pointers.

 On 24/04/15 21:30, Nils Gladitz wrote:

 On 24.04.2015 20:55, Gregor Jasny wrote:

 Hello,

 would it be possible to add generator expression support to CPack
 so that I can use $CONFIG within CPACK_PACKAGE_FILE_NAME? I'm
 using the CPack module from within my CMakeLists.txt.



From my understanding $CONFIG is a build time value.
evaluating $CONFIG at CPack time may be hard because
one can simply call:

cpack -G generator

then CONFIG definition is implicit and only known when the build tool is
called...





 I'm trying to generate unique file names per architecture and
 configuration but multi config generators like Xcode make this
 harder than expected.


 You should be able to do this without generator expressions and just
 CPACK_PROJECT_CONFIG_FILE [1] and CPACK_BUILD_CONFIG [2].
 If you really do require/want generator expressions you should be able
 to combine that with file(GENERATE) and include().


 Unfortunately the CPACK_BUILD_CONFIG approach does only work for
 multi-config generators. As far as I understand CPACK_BUILD_CONFIG gets
 only set if the -C command line option was given to cpack. But this option
 is only added conditionally and omitted for Makefile builds:

  void cmGlobalGenerator::CreateDefaultGlobalTargets(cmTargets* targets)
 ...
   if ( cmakeCfgIntDir  *cmakeCfgIntDir  cmakeCfgIntDir[0] != '.' )
 {
 singleLine.push_back(-C);
 singleLine.push_back(cmakeCfgIntDir);
 }


 Now I'm just wondering if conditionally setting -C / CPACK_BUILD_CONFIG is
 the right thing to do?


If it is possible to always define it may be it could be done.
Beware of backward compatibility issue though.


-- 
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] [CMake] [CPack] RPM generator creates %dir for /usr/local/xxx

[Eric Noulard]

2014-10-22 14:08 GMT+02:00 Domen Vrankar domen.vran...@gmail.com:

 Moving the conversation to developers mailing list.

 More docs on this for 2.8.12:

 http://www.cmake.org/cmake/help/v2.8.12/cpack.html#variable:CPACK_RPM_EXCLUDE_FROM_AUTO_FILELIST_ADDITION

 I guess that /usr/local may be added to
 CPACK_RPM_EXCLUDE_FROM_AUTO_FILELIST default list values.

 For Domen: see the history of this story here:
 http://public.kitware.com/Bug/view.php?id=13609


 I am familiar with this variable but I haven't noticed until now that not
 all the paths Dubrovskiy Viacheslav
 http://public.kitware.com/Bug/view_user_page.php?id=4130 listed in bug
 report were removed from auto listing.


This was a conservative choice in order to avoid backward compatibilty
issue.

I wasn't sure at that time that all (RPM-based) distros had the whole list
of dirs and I think there was at least some discrepancy between Fedora and
SuSE.
I was planning (in my mind) to craft a distro-specific list of excluded dir
into CPackRPM just in case...

Then ... nothing was done but the CPACK_RPM_EXCLUDE_FROM_AUTO_FILELIST*
vars :-(

-- 
Erk
L'élection n'est pas la démocratie -- http://www.le-message.org
-- 

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 and CPack automated testing

[Eric Noulard]

2014-10-15 9:30 GMT+02:00 Domen Vrankar domen.vran...@gmail.com:

 Hi,

 I was looking at CMake automated tests and did not quite understand how
 they are intended to be written.

 Do they only test for e.g. if CPack executes without errors or do they
 check generated files content (e.g. diff or call for e.g. rpm -qi
 some_pkg.rpm and then diff the output)? I'm not certain how in-depth the
 automated tests should be.


The current CPack test inside the CMake source tree are very simple they
only check whether if cpack runs properly in various situation
for various CPack generator. e.g. the CPackComponentsForAll test is run
for the available CPack generator on the current platform
and counts if the number of generated package file is the appropriate
one, see
CMakeRootSource/Tests/CPackComponentsForAll/RunCPackVerifyResult.cmake

The other tests CPackComponents and CPackTestAllGenerators only verifies
that cpack run and terminates OK.
The logic of activation of the various CPack generator is in:
CMakeRootSource/Tests/CMakeLists.txt

inside this file reads e.g.: if(CTEST_RUN_CPackComponentsForAll)  and the
following lines.

Doing more semantic checks e.g. running rpm -qi then compare to a
reference file etc... would be indeed very nice.
The thing is the combinatorial explosion of what you can generate for each
CPack generator is high but any more semantic
test for any CPack generator would be (I think) a good point.


 Is there a cmake developers wiki page or some other reference with
 guidelines on how to write automated tests for CMake and CPack?


I don't think there is anything like that, but that would be very helpful.



 Thanks,
 Domen

 --

 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




-- 
Erk
L'élection n'est pas la démocratie -- http://www.le-message.org
-- 

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] [CPack] [CPackRPM] mantis ticket 13176 CPackRPM support for per-component summary and description

[Eric Noulard]

2014-10-14 9:03 GMT+02:00 Domen Vrankar domen.vran...@gmail.com:

 Sorry for spamming...

 I noticed that the previous patch would break user provided rpm spec files
 so I'm attaching a new patch that fixes that problem with a bit more
 variable juggling.



Hi Domen,

I did re-assign the bug entry to you
http://public.kitware.com/Bug/view.php?id=13176

Then we discussing various patches I suggest you to attach the patch
directly to the tracker
that way it's easy to see the patch history and if ever some patch version
is obsolete you may simply remove it from the tracker.



 I also have a question. Would CPack also need something like
 CPACK_COMPONENT_component_PACKAGE_SUMMARY that could be used by
 CPACK_RPM_component_PACKAGE_SUMMARY as default value?



Not sure of that one.
We already have CPACK_COMPONENT_GROUP_CMAKE_DESCRIPTION
which may be a default value for CPACK_RPM_component_PACKAGE_
SUMMARY if packaging is done by compoent group (which is the default):

The behavior of the various CPack generator w.r.t. mono- or multi-
file/package generation vary,
see:
http://www.cmake.org/Wiki/CMake:Component_Install_With_CPack#CPack_Generator_specific_behavior

e.g. for NSIS or PackageMaker I don't know what you can do with
CPACK_COMPONENT_component_
PACKAGE_SUMMARY because there is only one package.

Otherwise I only read the patch and it looks good.

However you should at least:
  1) run ctest -R CPack  -- this the minimal way to run CPack related
tests in the CMake tree
  2) enhance or provide a specific test for the new behavior.


 Eric


 Thanks,
 Domen


 2014-10-14 0:23 GMT+02:00 Domen Vrankar domen.vran...@gmail.com:

 Message was sent to early by accident so I'm resending the rest.

 2014-10-14 0:17 GMT+02:00 Domen Vrankar domen.vran...@gmail.com:

 Hi,

 I extended the proposed patch for ticket 13176 with:
 - documentation section
 - CPACK_RPM_component_PACKAGE_DESCRIPTION fallback to
 CPACK_COMPONENT_compName_DESCRIPTION
 - handling of cases when one component sets its variable and the other
 doesn't


 e.g.
 #set(CPACK_RPM_test_PACKAGE_SUMMARY test_summary)
 set(CPACK_RPM_bin_PACKAGE_SUMMARY bin_summary)

 Could somebody please review the patch attached to this mail?



 Regards,
 Domen




 --

 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




-- 
Erk
L'élection n'est pas la démocratie -- http://www.le-message.org
-- 

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] What about #line like feature in cmake language?

[Eric Noulard]

2014-05-15 10:08 GMT+02:00 Nicolas Desprès nicolas.desp...@gmail.com:
 Hi,

 I am planning to develop a python generator of CMakeLists.txt file for
 easier integration in an already existing tool. This approach is different
 from the others approaches consisting in binding the CMake language in a
 foreign languages. Lua, Javascript and Python have already been tried
 without success to my knowledge. Generating CMakeLists.txt files seems a
 simpler approach to me since the CMake language is very stable and it keeps
 the two projects separated. Finally it reaches the same goal since the idea
 behind binding CMake in a foreign language is too gain a more general
 purpose and feature full language with a larger standard library.

 To assist in such a task the CMake language could provide a command similar
 to the #line directive found in the C-pre-processor. Changing the filename
 and line number in the CMakeLists.txt file would make the generator able to
 transparently run CMake behind the scene while the errors reported by CMake
 would still refer to the generator input file written by the user.

 The last time I checked I could not find such a feature in CMake.

Did you check those var:
CMAKE_CURRENT_LIST_DIR
CMAKE_CURRENT_LIST_FILE
CMAKE_CURRENT_LIST_LINE

message(STATUS ${CMAKE_CURRENT_LIST_LINE}: ${CMAKE_CURRENT_LIST_FILE}
Your message)

should print the line number and filename with Your message.

Is it the kind of feature you are looking for?


  I am realizing that since version 3 is still under development it might be a 
 good
 occasion to show up and mention it here. I think that it is not a big change
 to CMake and that it should not overload the maintenance process. I hope it
 is not too late for such a proposal since the 5th candidate has just been
 released.

CMake 3 is in RC process I doubt that adding new feature is possible
at this stage.


-- 
Erk
L'élection n'est pas la démocratie -- http://www.le-message.org
-- 

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/cgi-bin/mailman/listinfo/cmake-developers

[cmake-developers] CMake: Compile error: /usr/bin/ld: cannot find -lQt5::WinMain

[Eric Noulard]

Hi all,

Current master  and 3.0.0-rc2 give compile error:

/usr/bin/ld: cannot find -lQt5::WinMain
collect2: error: ld returned 1 exit status

This is on Debian Jessie 64bit linux box,
with gcc 4.8.2 compiler

git bisect leads me to

61c60b239c0ddc5eb975bb9cc3721b792a2aa18f is the first bad commit
commit 61c60b239c0ddc5eb975bb9cc3721b792a2aa18f
Author: Stephen Kelly steve...@gmail.com
Date:   Wed Mar 12 16:58:03 2014 +0100

QtDialog: Avoid linking to Qt4 WinMain when using Qt 5.

Override the QT_QTMAIN_LIBRARY cache variable with a regular
variable in the Qt 5 configuration. This avoids linking with the
Qt 4 version of the WinMain library.


-- 
Erk
L'élection n'est pas la démocratie -- http://www.le-message.org
-- 

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/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] RFC: add version to project() call

[Eric Noulard]

2014-02-03 Brad King brad.k...@kitware.com:
 On 02/02/2014 03:49 PM, Stephen Kelly wrote:
 Should this topic set the CPACK_PROJECT_VERSION variable? Or should cpack
 first try to read PROJECT_VERSION, and only use CPACK_PROJECT_VERSION as a
 fallback?

 I think it should read CPACK_PROJECT_VERSION and if that is not set
 then try PROJECT_VERSION.  The CPACK_ name is more specific.

+1 this has always been the case: i.e. prefer more specific var if defined.

Have a look at CPack.cmake and you'll see statement like:

cpack_set_if_not_set(CPACK_PACKAGE_NAME ${CMAKE_PROJECT_NAME})

in the same way you may have CPack generator specific var as well, like:
CPACK_RPM_PACKAGE_NAME.
This last var is used by RPM generator. It gets its default value from
CPACK_PACKAGE_NAME
unless it has been set by the user.

that said CPACK_PROJECT_VERSION does not currently exist.
however there is:
CPACK_PACKAGE_VERSION
CPACK_PACKAGE_VERSION_MAJOR
CPACK_PACKAGE_VERSION_MINOR
CPACK_PACKAGE_VERSION_PATCH
currently MAJOR/MINOR/PATCH have a default builtin value 0.1.1.

Those variables define the **package** version which may or may not be the
same as **project/software** version. i.e. the version of the package may
be different as the version of the thing being packaged.

So do you want:

1) to create new CPACK_PROJECT_VERSION vars?
If yes, what is the purpose?

2) feed current CPACK_PACKAGE_VERSION* vars with the one found in
CMAKE_PROJECT_VERSION* ?


If 2) this will change the default behavior (sorry if I loose the
track of default behavior with or without the ploicy).

-- 
Erk
L'élection n'est pas la démocratie -- http://www.le-message.org
-- 

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] Problem with sphinx

[Eric Noulard]

2013/12/15 Alexander Neundorf neund...@kde.org:
 Hi,

 I have a problem with the new documentation system, it complains that it can't
 load the extension cmake because the module error_reporting is missing.
 That's what I get when I do make documentation:

 [100%] sphinx-build html: see Utilities/Sphinx/build-html.log
 cd /home/neundorf/src/CMake/build/Utilities/Sphinx
/usr/bin/sphinx-build -c /home/neundorf/src/CMake/build/Utilities/Sphinx
-d /home/neundorf/src/CMake/build/Utilities/Sphinx/doctrees
-b html /home/neundorf/src/CMake/cmake/Help
   /home/neundorf/src/CMake/build/Utilities/Sphinx/html  build-html.log
 Extension error:
 Could not import extension cmake (exception: No module named error_reporting)
 make[3]: *** [Utilities/Sphinx/doc_format_html] Error 1

 The directories are all ok.
 build-html.log contains:
 Running Sphinx v1.1.3

 Python docutils 0.9 are installed. It seems somehow docutils.error_reporting
 is missing. This is on a SUSE 12.2, using python 2.

 Is the installed docutils package somehow not new enough ?

I don't have this issue with current CMake master
I'm using Sphinx 1.1.3, Python 2 and docutils 0.11.

docutils 0.10 seems to have
enhanced math and error handling.

see:
http://docutils.sourceforge.net/RELEASE-NOTES.html#release-0-11-2013-07-22

it seems that error_reporting has been moved from
http://sourceforge.net/p/docutils/code/HEAD/tree/tags/docutils-0.9/docutils/error_reporting.py
to
http://sourceforge.net/p/docutils/code/HEAD/tree/tags/docutils-0.10/docutils/utils/error_reporting.py


-- 
Erk
L'élection n'est pas la démocratie -- http://www.le-message.org
--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] new topic make-cpack-options-boolean

[Eric Noulard]

2013/11/20 Nils Gladitz nilsglad...@gmail.com:
 The state of CPack component and group options currently depends on them
 being defined and not on their specific boolean value.

Yes this has been like that for ages...in some CPack code.

 This is not only unexpected but also breaks with the CPackComponent macros
 which set these options to FALSE per default.

We have been bitten by that in the past already see:
http://public.kitware.com/Bug/view.php?id=13490#c30770

see commit 561b4baead36227bdd0bf1368c05e4f3d035a083

(this was my mistake though -:) ).

 The new topic make-cpack-options-boolean changes that behavior.
 Would this be ok for next?

I guess that the correct behavior is to use IsON everywhere.
CPACK_MONOLITHIC_INSTALL is already checked with
IsOn at one place and IsSet in another...

For the other variables related to component keeping only
IsON should Ok for next as-is because it is clearly an error to use IsSet
in this case. So I guess it won't break anything to enforce that.

So for me, this seems good for next.


 Nils
 --

 Powered by www.kitware.com

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

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

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



-- 
Erk
L'élection n'est pas la démocratie -- http://www.le-message.org
--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] cmake --help output indentation (was: RST and documentation)

[Eric Noulard]

2013/11/21 Stephen Kelly steve...@gmail.com:
 Brad King wrote:
 IMO the --help-* command-line options are
 still present only for basic compatibility with pre-3.0 help and
 should not be a focus of workflow enhancements.

 I don't consider --help-command an 'only compatibility' feature. It's the
 primary way I read cmake documentation.

+1
Same for me.
The same is true for --help-variable
for both CMake and CPack and was expecting the same thing for CTest.

I did already said that and Brad answered that:

1) He doesn't want to filter command/variable between CMake/CPack/CTest
   http://public.kitware.com/pipermail/cmake-developers/2013-October/008610.html
   http://public.kitware.com/pipermail/cmake-developers/2013-October/008615.html

2) He doesn't want to dynamically parse rst files so that
directive-defined variables
(or command) do not currently appear in --help-[variable|command][-list]

From my point of view this is a great feature loss because:

I almost only use --help-xxx to get documentation.
I like the dynamicity of pre-doc-move CPack documentation dynamicity where
if you change your CPack.cmake module the command line doc gets
automatically
updated as well.

I think that Sphinx batch processing for browsable and indexed doc is great
but it does not means that the --help-xxx is made obsolete.

 The output of the
 individual domain objects is still pretty easy to use.

 By 'domain object', do you mean the individual .rst files? How would you
 read them without --help-command and without find+cat? How find+cat easier
 than --help-command?

 All the
 other output is just whole man pages which are better viewed with
 real man page or html viewers.

 The --help-command option is much more convenient than

  man cmake-commands
  /find_package
  n # enough times to get to the find_package docs, not references to it.

 It is also a disadvantage that the man context is not the command line
 context. Think of when you use cat or head instead of vi/less.

 Are you referring to something more convenient? I'm not a man page expert.
 There may be another way to get to the find_package docs than the above?

+1 again.
Not mentionning that if you have a shell with properly configured completion
you are **very efficiently accessing the doc** with

cmatab  -- cmake
cmake --help-coTAB -- cmake --help-command
cmake --help-command find_pacTAB -- cmake --help-command find_package

currently I can obtain (almost) the information

cmake --help-manual cmake-commands | less
/find_package$

You won't get other reference with the $ at the end.
Completion is more efficient because it is more tolerant to
typing error because you type less character.


I'd really like to have a command line tool with dynamic doc features.
If it's considered too costly for cmake/ctest/cpack then may be
I can try to craft a cdoc command line tool which can do just that.

Note that current sphinx generated documentation (I tested HTML)
contains directive-defined variable/command in the index only.

Utilities/Sphinx/html/genindex.html

you don't get any in:
Utilities/Sphinx/html/manual/cmake-variables.7.html
Utilities/Sphinx/html/manual/cmake-commands.7.html
nor in:
Utilities/Sphinx/html/commands/*
Utilities/Sphinx/html/variables/*

i.e. cpack_add_component is only there:
Utilities/Sphinx/html/module/CPackComponent.html#command:cpack_add_component
or CPACK_PROJECT_CONFIG_FILE only there:
Utilities/Sphinx/html/module/CPack.html#variable:CPACK_PROJECT_CONFIG_FILE

I would have expected those vars to appear in commands and variables.

-- 
Erk
L'élection n'est pas la démocratie -- http://www.le-message.org
--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] CPack BAR package generator

[Eric Noulard]

2013/10/29 David Cole dlrd...@aol.com:
 Stephen Kelly steveire@... writes:
  Do you have any thoughts on the CPACK_PACKAGE_CONTACT problem?

 Namely that

  the debian generator and the BAR generator have differing

 expectations on

  what such a thing would contain. Should we have separate
  CPACK_PACKAGE_CONTACT_NAME and CPACK_PACKAGE_CONTACT_EMAIL

 variables?


 Eric, do you have any thoughts on this issue?

Sorry Steve,

But my bandwidth on the CMake/CPack front is currently so low that I can barely
follow CMake ML discussion correctly.

 I'll soon try to revive this. See the discussion so far at:

  http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/7530

I remember but I have no time to help further right now and for 3 up
to 4 weeks from now.

 What about using the typical format that contains both name and email
 address in CPACK_PACKAGE_CONTACT? Would David Cole dlrd...@aol.com work
 if used in that context for both of these generators...? Or would that make
 one of them choke?

This is OK with Debian. Note that concerning Debian, CPACK_PACKAGE_CONTACT
is used as a deafult value for CPACK_DEBIAN_PACKAGE_MAINTAINER which
is mandatory.

If ever the chosen common format for CPACK_PACKAGE_CONTACT is not suitable
as-is for filling CPACK_DEBIAN_PACKAGE_MAINTAINER we may be able to
automatically
extract the relevant bits from CPACK_PACKAGE_CONTACT in order to put appropriate
value in CPACK_DEBIAN_PACKAGE_MAINTAINER.


Currently we simply do:
# Maintainer: (mandatory)
if(NOT CPACK_DEBIAN_PACKAGE_MAINTAINER)
  if(NOT CPACK_PACKAGE_CONTACT)
message(FATAL_ERROR CPackDeb: Debian package requires a
maintainer for a package, set CPACK_PACKAGE_CONTACT or
CPACK_DEBIAN_PACKAGE_MAINTAINER)
  endif()
  set(CPACK_DEBIAN_PACKAGE_MAINTAINER ${CPACK_PACKAGE_CONTACT})
endif()

 References:

 http://stackoverflow.com/questions/2631065/what-is-the-format-of-email-header-name-email
http://tools.ietf.org/html/rfc2822#section-3.4

David Cole dlrd...@aol.com works fine as-is for .deb.
The regex shown on the Stackoverflow article is scary.

I guess CPack does not have to validate that.

-- 
Erk
L'élection n'est pas la démocratie -- http://www.le-message.org
--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] CPack: 7-zip generator

[Eric Noulard]

2013/10/11 Alexander Neundorf neund...@kde.org:
 On Friday 11 October 2013, you wrote:
 On Fri, Oct 11, 2013 at 5:40 PM, Alexander Neundorf neund...@kde.orgwrote:
  The thread looks somewhat unfinished, and Ralf simply didn't seem to
  reply anymore, it would have needed just some more pushing to get it in.

 What kind of pushing? Code polishing? Documentation? Tests?

 Well, there was no acxtivity from Ralf anymore, and Eric is mostly maintaining
 cpack.

Just to precise what I usually do a little.
I try hard to give valuable advice and/or lool on CPack questions, however
I seldomly use Windows so that I'm not good at testing Windows related
CPack generator
beside proof-reading the code.

The first step would be to update the patch against current master
and verify that all CPack* tests are ok.

 Maybe you can push the code in a branch on cmake stage and try to get it
 accepted into master ?

That would be the best approach, and may be opening a feature request
in the tracker as well:
http://public.kitware.com/Bug/main_page.php


 Alex

 --

 Powered by www.kitware.com

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

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

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



-- 
Erk
L'élection n'est pas la démocratie -- http://www.le-message.org
--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] Converting CMake documentation to reStructuredText and Sphinx

[Eric Noulard]

2013/10/10 Brad King brad.k...@kitware.com:
 Hi Folks,

 The need for a more flexible documentation system has come up a few
 times and proposals for new general-purpose documentation sections
 were made at least in two threads:

  Adding some generic section to the docs ?
  http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/5924

  cmake --help-concept
  http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/7799

 CMake's builtin documentation generation using C++ string-literals
 with simple indented = preformatted markup has served us well for
 many years but it is time to move to something better.  Lightweight
 markup languages have a similar feel to our existing system but are
 much more widely used and mature.  After considering markup languages
 such as Markdown and AsciiDoc I settled on reStructuredText:

  http://docutils.sourceforge.net/docs/ref/rst/restructuredtext.html

 It has a great extension mechanism and is supported by fantastic
 tools like Sphinx to handle suites of multiple document files with
 cross-referencing links among them:

  http://sphinx-doc.org/

 -

 I've prototyped a topic branch to convert CMake's documentation over
 to .rst source files and build them using Sphinx.  It is published
 in my Github repository:

  https://github.com/bradking/CMake/tree/doc-reStructuredText

 The last commit adds the generated man and html files for purposes
 of demonstration.  Read the commit message to see how to view them.
 I also temporarily published the generated html documentation here:

  http://www.cmake.org/cmake/help/v2.8.12.20131009-g9a890/
  (Try out the Index and Search pages!)

 Take a look at the converted documentation sources here:

  https://github.com/bradking/CMake/tree/doc-reStructuredText/Help

 Note that the conversion process is automated so the document files
 can be made better with manual tuning over time after the permanent
 conversion is done.  We can also add arbitrary new manual pages
 pretty easily as demonstrated by the cmake-generator-expressions
 page.

 The topic includes a cmRST class that does basic reStructuredText
 processing so that most of the --help-* options can continue to
 work.

 -

 The topic also defines Sphinx extensions to add reStructuredText
 directives for cmake domain objects like commands and variables.
 This can be used to add indexed and x-refable variable documentation
 inside .cmake module files.  Module files can contain rst markup
 inside comments.  For example, here is part of Modules/CPack.cmake:

  #.rst:
  # CPack
  # -
  #
  # Build binary and source package installers.
  #
  # Variables common to all CPack generators
  # 
  #
  [snip]
  #
  # .. variable:: CPACK_PACKAGE_NAME
  #
  #The name of the package (or application). If
  #not specified, defaults to the project name.

 It gets loaded from a Help/module/CPack.rst document containing

  .. cmake-module:: ../../Modules/CPack.cmake

 where cmake-module is a directive added in our Sphinx extension
 that knows how to scan .cmake comments to extract #.rst: blocks
 (which can now be anywhere in the file e.g. next to macro defs).

 Variables and commands defined with directives like the above can
 be cross-referenced with cmake domain roles e.g.

  See the :variable:`CPACK_PACKAGE_NAME` variable...

 Our Sphinx extension also automatically transforms all documents
 in Help/type/*.rst files to cmake domain objects of type so
 they are indexed and can be cross-referenced e.g.

  See command :command:`add_dependencies` to add target-level deps.
  See the :prop_tgt:`OUTPUT_NAME` target property to set a file name.
  See the :variable:`CMAKE_LANG_FLAGS` to add flags.

 -

 Since this topic makes sweeping changes throughout the source code
 we'll have to schedule a flag day on which I will freeze the
 repository and apply the permanent conversion.  Currently I plan
 for this to be just after 2.8.13 is released.


This is all very good news.
This will certainly provide a big step forward more up-to-date and
easy to access documentation.

I did not have time to try the branch yet but I'll try it ASAP and
provide feedback when done.

I have preliminary question though, since those change makes it possible
to write documentation without touching the code are you planning to
add missing --help- to ctest ?

e.g. ctest --help-variable does not currently exist and it would be nice
to have all cmake/ctest/cpack prepared with almost the same set
of --help- command line options with associated .rst files
which could be easily patched/updated/added in order to create
more documentation.

Did you plan something along that line?


-- 
Erk
L'élection n'est pas la démocratie -- http://www.le-message.org
--

Powered 

Re: [cmake-developers] bash-completion: filtering out version line more robustly

[Eric Noulard]

Hi Brad,

I think it would be simpler to use

grep -v  

because help-*-list never contains a space (no variable or command
have embedded space)
I think you missed a couple of cases in the cmake completion.

My proposal is in stage branch:

bash-completion-improvement

Sidenote along bash completion feature:

completion of variables containing   are not working that well

try:

$ cmake --help-variable CMAKE_L

which does not work
whereas

$ cmake --help-variable CMAKE_L

works. I tried (a little) to force   when a variable contain  or
 without success
if anybody here knows an easy way to do that it would be nice to have :-]



2013/9/25 Brad King brad.k...@kitware.com:
 Eike, Eric, Igor,

 Please take a look and try out this change to bash-completion:

  http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c5ee80b6

 As explained in the commit message I'd like it to be robust to
 the cmake version line being removed from the beginning later.

 One can test it with the version dropped by editing the
 cmDocumentation::PrintDocumentation method to drop the
 conditional block that calls PrintVersion:

  
 http://cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmDocumentation.cxx;hb=v2.8.11.2#l310

 I'd like to get a version of bash-completion out there for a
 while before actually dropping the version number line since
 people may not always use matching versions.

 Thanks,
 -Brad



-- 
Erk
L'élection n'est pas la démocratie -- http://www.le-message.org
--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] Patches for some clang warnings

[Eric Noulard]

2013/9/24 Brad King brad.k...@kitware.com:
 Hi Eric,

 On 09/19/2013 03:53 PM, Brad King wrote:
 On 09/19/2013 03:34 PM, Sean McBride wrote:
 Thanks.  Here are two more patches.

 Sean's -Wdocumentation build produces these warnings:

 .../Source/CPack/cmCPackGenerator.h:163:38: warning: empty paragraph passed 
 to '@param' command [-Wdocumentation]
* @param[in] initialPackageFileName
  ^
 .../Source/CPack/cmCPackGenerator.h:164:36: warning: empty paragraph passed 
 to '@param' command [-Wdocumentation]
* @param[in] groupOrComponentName
  ~~^
 .../Source/CPack/cmCPackGenerator.h:165:27: warning: empty paragraph passed 
 to '@param' command [-Wdocumentation]
* @param[in] isGroupName
  ~^
 .../Source/CPack/cmCPackGenerator.h:175:10: warning: empty paragraph passed 
 to '@pre' command [-Wdocumentation]
* @pre @ref toplevel has been filled-in
  ^

 Can you please fill in the docs for these?

Yep.
Just done and merged to next:

Fetching upstream next
Merge topic 'fixDocumentationComment' into next

e507bf2 CPack: Fix clang -Wdocumentation warnings


-- 
Erk
L'élection n'est pas la démocratie -- http://www.le-message.org
--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] CPack BAR package generator

[Eric Noulard]

2013/9/20 Stephen Kelly steve...@gmail.com:
 Stephen Kelly steveire@... writes:
  https://gitorious.org/~steveire/cmake/steveires-cmake

 It is the start of a CPack generator for BlackBerry BAR packages, required
 for deployment to those devices. I haven't worked much with CPack before, so
 I'd appreciate some feedback even at this early point.


 Eric, and response to this?

I'm looking at it right now.

1) You lack at least a CPackBAR.cmake in which you should put
   the documentation for each CPACK_BAR_xx specific variable usage.
   Have a look at CPackWIX.cmake or CPackRPM.cmake etc

   You can check if it's working with:
   cpack --help-variable CPACK_BAR_xx

2) You shouldn't do

   add_custom_target(bbpackage
   COMMAND ${CMAKE_CPACK_COMMAND} -G BAR
   )

but

set(CPACK_GENERATOR BAR)

then make package or cpack with no args in the build tree should
biuld a BAR package.
see cpack --help-variable CPACK_GENERATOR

   3) Depending on how much flexibility you want you may chose to do
some of the work
   inside a CMake script like CPackRPM.cmake does or do all you want to do
   inside the C++ code (cmCPackBARGenerator::PackageFiles) like
NSIS or DEB does.
   Offering some trap in your CPackBAR.cmake may ease

   4) You should obviously have some tests for it. (CMakeSource/Tests/CPack*)
 4.1) ensure that CPackTestAllGenerators/ works
and may be CPackComponents/
CPackComponentsForAll/  as well.

 4.2) develop BAR specific test like for CPackWiXGenerator/

I do not have the time to do a test build yet, but I'll try.




 Thanks,

 Steve.

 --

 Powered by www.kitware.com

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

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

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



-- 
Erk
L'élection n'est pas la démocratie -- http://www.le-message.org
--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] CMake libarchive bug? (not new...)

[Eric Noulard]

2013/9/15 Alan W. Irwin ir...@beluga.phys.uvic.ca:
 On 2013-09-14 15:08-0400 David Cole wrote:

 Ah, of course. A symlink. Thank you.

 Yes, I'm on Windows and using the pre-built binaries of CMake from
 cmake.org.

 It's annoying that cross-platform projects actually have symlinks in their
 source trees.


 Symbolic links are extremely useful and therefore used in a number of
 cross-platform software projects that are primarily developed on
 Linux.  So projects like subversion (and git?) recognize this
 situation and replace the symlink with the corresponding file copy for
 platforms such as Windows that do not have good symlink support.

This is a long-standing issue for CPack:
http://public.kitware.com/Bug/view.php?id=13251

Since we rely on libarchive it should certainly be handled by libarchive itself:
http://code.google.com/p/libarchive/issues/detail?id=259


 I strongly feel that tarball unpacking software should follow this
 same course as well rather than asking all cross-platform projects to
 give up symlinks on platforms that support them.

[...]

I strongly suiggest you to add your comment on librarchive tracker
http://code.google.com/p/libarchive/issues/detail?id=259
and/or
CPack bug entry
http://public.kitware.com/Bug/view.php?id=13251


-- 
Erk
L'élection n'est pas la démocratie -- http://www.le-message.org
--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] CMake libarchive bug? (not new...)

[Eric Noulard]

2013/9/14 David Cole dlrd...@aol.com:
 CMake 2.8.12-rc3 cannot extract these .tar.gz files via cmake -E tar xzf:

https://github.com/zeromq/zeromq3-x/archive/v3.2.2.tar.gz
https://github.com/zeromq/zeromq3-x/archive/v3.2.3.tar.gz
https://github.com/zeromq/zeromq3-x/archive/master.tar.gz

 But this is not a recent (if at all) regression, 2.8.10 and 2.8.11 also fail
 to extract them...

 There's also an error if trying to extract the equivalent .zip files
 (replace .tar.gz with .zip in the URLs...)

 It is always on the same file, doc/zmq_epgm.txt, with output like this:

This file is a symbolic link:
lrwxrwxrwx root/root 0 2013-08-24 08:09
zeromq3-x-master/doc/zmq_epgm.txt - zmq_pgm.txt


I don't have any trouble using
cmake version 2.8.11.20130914-g396df-dirty
(git master)

Q1) Do you do the extraction on Windows or Linux?
   If you are on Windows then this is the well-know trouble
   of unsupported lilbarchive feature on Windows.
   Dig the CMake ML and/or libarchive tracker and you'll find out.

Q2) Is your CMake compiled with system libarchive or the one thar
comes with CMake ?


 -- extracting... [tar xfz]
 CMake Error: Problem with archive_write_header(): Can't create
 '\\?\C:...\src\ex-download-zeromq1234\zeromq3-x-3.2.3\doc\zmq_epgm.txt'
 CMake Error: Current file: zeromq3-x-3.2.3/doc/zmq_epgm.txt
 CMake Error: Problem extracting tar:
 C:/.../Downloads/zeromq3-x-v3.2.3.tar.gz
 -- extracting... [error clean up]
 CMake Error at
 C:/.../download-zeromq-prefix/src/download-zeromq-stamp/extract-download-
 zeromq.cmake:33 (message):
  error: extract of 'C:/.../Downloads/zeromq3-x-v3.2.3.tar.gz'
  failed

 CMake bug? Libarchive bug? Maybe fixed already upstream?

 One more tidbit: 7-zip *can* extract the archives just fine, so I don't
 think there's anything unrecoverably wrong with the archive files
 themselves.

 Anybody have a quick fix or a workaround I can use?

 (I'm not a fan of using 7-zip for the extraction, or of using git snapped
 to a tag: I'm trying to make a super build work with just cmake -E and
 .tar.gz files. If I must, I'll simply create a new tar.gz without the file
 that's making it choke, and use that... I'd really prefer to use the
 official one from github, though. So I don't have to host a custom one
 anywhere...)


 Thanks,
 David C.

 --

 Powered by www.kitware.com

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

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

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



-- 
Erk
L'élection n'est pas la démocratie -- http://www.le-message.org
--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] CPack generators for IPS (Solaris 11), depot (HPUX), etc.

[Eric Noulard]

2013/9/10 Magnus Johansson magnus.johans...@foxt.com:
 I am wondering if anyone has experimented with generators for:

 IPS, Image Packaging System (Solaris = 11)
 PKG (Solaris = 10)
 Depot (HPUX)
 RPM (for AIX)

 As far as I can see there is no support for these. I thought RPM for AIX
 would be easy, but my first try failed since the rpmbuild command did not
 exist on my AIX machines. I will investigate this further, but I am curious
 if anyone has successfully built RPMs for AIX.

Not me but I wrote the RPM generator and its only dependence are

1) CMake itself
2) rpmbuild command

so besides that it shoud work on AIX or any other system equipped
with cmake and rpmbuild.

 I would also like to know what kind of effort is involved in writing a new
 generator. I had a brief look at the source code for the RPM generator, and
 it seemed fairly straight forward, but I would like some input from someone
 who has actually written a generator.

Writing a new generator is not difficult, however supporting all CPack feature
may be a fair amount of work, e.g. supporting COMPONENTized packaging.

When you write a new generator you must:
  1) update and verify that CPack* test are OK
  2) write any generator specific case needed.
  3) Provide documentation for generator specific variables
  in Modules/CPackGEN.cmake file.
  so that cpack --help-variable CPACK_GEN_ is available.


-- 
Erk
L'élection n'est pas la démocratie -- http://www.le-message.org
--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] Getting a list of files to install and their destination

[Eric Noulard]

2013/9/5 Brad King brad.k...@kitware.com:
 On 09/05/2013 08:14 AM, Stephen Kelly wrote:
 limitation of that is that install(SOURCE) and install(CODE) can do
 arbitrary things.

 Yes.  There are also modifications made to the installed files for
 things like runtime path.  Installation is procedural, not declarative.
 There is no way to predict the results without just doing it.

Non mentioning

 INSTALL(DIRECTORY)
 INSTALL(FILES)
 INSTALL(PROGRAMS)

All those INSTALL(xxx) commands ends-up in

FILE(INSTALL ...)
command inside generated cmake_install.cmake files.

You'll discover the FILE(INSTALL...) command has undocumented internal
parameters which are used in cmake_install.cmake.



 Am I right in saying that even for remote deployment, cmake will not
 transfer files which are not changed?

 If the modification times are identical then CMake will not update
 the installed file.  If they are different, in either direction,
 CMake will install and make the modification times the same.

Which implies CMake would have to find a way to check modif' times on
the remote target
AND ensure that host and target share the same time reference.

If you want to avoid that you'll have to maintain some local (to the
host) mean which
proves that currently built file/taregt is not different from the
previously installed one.
A possible mean would be to build a hash of each installed file inside
the install
step.

In the 3 options described there:
http://thread.gmane.org/gmane.comp.lib.qt.creator/8995

1) use CPack
2) use make install to tmp and deploy

are almost the same because CPack precisely install to a temp location before
building the package, so that creating the CPack generator that does:

   a) deploy
   b) create some CMakeDeployment.txt

seem quite easy and similat to 2).

CPack usually throw away its tmp dir before each packaging request, however
a specific generator may certainly be taught not to do so in order to
spare some time
and rely on install to do this in an appropriate manner.

This CPack Deploy generator would then be able to only transfer the
updated files.

Note that following the same idea CMake already creates
install_manifests.txt file.
You can grep the source for CMAKE_INSTALL_MANIFEST and see that is is handled
by the FILE( ..) command.

The manifest file is create by the very end of toplevel
cmake_install.cmake script
after all FILE(...) have run.


-- 
Erk
L'élection n'est pas la démocratie -- http://www.le-message.org
--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] Where to document the graphviz options ?

[Eric Noulard]

2013/7/24 Alexander Neundorf neund...@kde.org:
 Hi,

 using cmake --graphviz=filename .
 you can generate graphs showing the dependencies between the targets.
 If present, cmake will read a CMakeGraphVizOptions.cmake file, and use options
 from it, e.g. GRAPHVIZ_GRAPH_TYPE and GRAPHVIZ_EXTERNAL_LIBS.
 AFAIK this is not documented anywhere, and I would like to change this.

 But where should I put this information ?

I would suggest to document it inside CMakeGraphVizOptions.cmake
using basic markup used for documenting CPack generators.
Then simply make cmake parse the file the way cpack does and you'll
get the variables
(or macro/functions) documented in --help-variable-*

 Simply list the variables in the variables section, and mention that they need
 to be set in a CMakeGraphVizOptions.cmake file ?
 Better ideas ?

Nope.

-- 
Erk
L'élection n'est pas la démocratie -- http://www.le-message.org
--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] Unexpected bad status for file DOWNLOAD for http://*.xz URLs

[Eric Noulard]

2013/7/12 Alan W. Irwin ir...@beluga.phys.uvic.ca:
 On 2013-07-11 16:30-0700 Alan W. Irwin wrote:

 These commands

 file(DOWNLOAD
 http://download.gnome.org/sources/glib/2.32/glib-2.32.1.tar.xz;

 /home/software/plplot_svn/HEAD/plplot_allura/cmake/build_projects/cmake_downloaded_glib-2.32.1.tar.xz
 SHOW_PROGRESS STATUS status)
 message(STATUS Download status = ${status})

 instantly give me the following results:

 -- [download 0% complete]
 -- Download status = 1;unsupported protocol

[...]

Then may be the unsupported protocol is not http...keep reading


 So I hope someone else will also try experiments to see if they can
 discover _any_ http://*.tar.xz URL that can be downloaded by
 file(DOWNLOAD...).

If I use the curl -L options you use I can see:

GET /sources/glib/2.32/glib-2.32.1.tar.xz HTTP/1.1
Location: https://download.gnome.org/sources/glib/2.32/glib-2.32.1.tar.xz
Issue another request to this URL:
'https://download.gnome.org/sources/glib/2.32/glib-2.32.1.tar.xz
GET /sources/glib/2.32/glib-2.32.1.tar.xz
Location: http://ftp.gnome.org/pub/GNOME/sources/glib/2.32/glib-2.32.1.tar.xz
Issue another request to this URL:
'http://ftp.gnome.org/pub/GNOME/sources/glib/2.32/glib-2.32.1.tar.xz
GET /pub/GNOME/sources/glib/2.32/glib-2.32.1.tar.xz
...

then it seems that the initial http URL is redirected to https which
is redirected to ftp...

then I tried my CMake build with with your:
file(DOWNLOAD
http://download.gnome.org/sources/glib/2.32/glib-2.32.1.tar.xz;
/tmp/cmake_downloaded_glib-2.32.1.tar.xz
SHOW_PROGRESS STATUS status)
message(STATUS Download status = ${status})

and it works as expected.

so my best bet is that the CMake command your are using has no SSL support
which makes the https handling fail with unsupported protocol.


--
Erk
L'élection n'est pas la démocratie -- http://www.le-message.org
--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] Using multiple toolchains

[Eric Noulard]

2013/7/8 Alexander Neundorf neund...@kde.org:
 On Friday 05 July 2013, Eric Noulard wrote:
  I don't think an inappropriate amount of work or fundamental change to
  cmake is required to achieve step 2.

 innappropriate amount heavily depends on who is doing the job but I guess
 that the already proven workload given by Stephen to CMake speaks for
 itself. I'm pretty sure he'll manage to do that.

 Since this involves changes quite in the core of cmake, I'm quite sure
 somebody (Brad) would have to invest about the same amount of time into this
 as Stephen. So it's not only the question whether Stephen would be able to do
 it, but also whether there is a reviewer with enough time.

Yes right, I value your opinion..
I was only giving my point of view no more.

And I did say that:

The main issue would be, could it become a nightmare to maintain?

Giving a fair amount of time one time may be done
ensuring long term support may be difficult.

--
Erk
L'élection n'est pas la démocratie -- http://www.le-message.org
--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] Using multiple toolchains

[Eric Noulard]

2013/7/4 Stephen Kelly steve...@gmail.com:
[...]

 My approach comprises several steps:

 1. Refactor cmake so that more that one toolchain can be available at
a time.
 2. Make host+target builds possible in a single buildsystem by initializing
both the host and the target toolchain, specifying whether to find
dependencies in the host or the target, and specifying whether to build a
particular cmake-target for the host or for the target system. This does
not expose us to problems of clashes of cmake-target names for multiple
toolchains or problems of defining multiple per-toolchain make-targets
for a single cmake-target as all of those things remain impossible at
this step. This step requires some way to define such distinctions in
front-end CMakeLists.txt files. Possibly something like a toolchains()
command scoped to end with a endtoolchains() command.
 3. Make it possible to define multiple toolchains to build a single target
for. Still only two toolchains are possible (host+target), but now we can
define that a single cmake-target created with add_executable should be
built for both the host and the target. Consider moc for example, which
might make sense to build for both so that target-on-target builds (or
target-in-target-vm builds) can be done. In addition to step two, this
step requires solving the disabmiguation problems of cmake-targets and
other problems that come from using multiple toolchains from one
cmake-target definition.
 4. Make it possible to use N target toolchains. This takes advantage of the
solutions created in step 3. In addition to step 3, this step requires
deprecation of the undocumented CMAKE_TOOLCHAIN_FILE in favor of
something which can be a list, and it requires some way of attaching
names to toolchains. Projects using this have the disadvantage that there
is nothing but convention to standardise toolchain names. One project
might use RaspPi as a toolchain name in a CMakeLists.txt file, while
another uses RaspberryPi and yet another Raspbian. Qt has a similar issue
with device mkspec names.

 While the work in your branch has gotten
 impressively far, it also serves to demonstrate the inherent
 complexity of the proposed approach.  IMO it is not worth exploring
 that approach further.  Sorry.

 That reaction is not what I was hoping for. :)

I was surprised by Brad's answer as well.

 My branch makes a start mostly on steps 1 and 2 above, and to a small
 extent, step 4. 80% of the motivation and value of multiple toolchains comes
 from step 2, so I would happily truncate the other two as goals or leave
 them to future exporation.

+1
I do agree with that, I'm seldomly do cross-compiling but when I do
miss the native+target compilation I was used to when I was using
hand-written recursive makefile system 10+ year agos.

 I don't think an inappropriate amount of work or fundamental change to cmake
 is required to achieve step 2.

innappropriate amount heavily depends on who is doing the job but I guess
that the already proven workload given by Stephen to CMake speaks for itself.
I'm pretty sure he'll manage to do that.

The main issue would be, could it become a nightmare to maintain?

I did not manage to have so much time on the CMake front lately but
I'll try to follow and test Stephen work on that if it is going on.


--
Erk
L'élection n'est pas la démocratie -- http://www.le-message.org
--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] Using multiple toolchains

[Eric Noulard]

2013/7/4 Stephen Kelly steve...@gmail.com:
[...]

 My approach comprises several steps:

 1. Refactor cmake so that more that one toolchain can be available at
a time.
 2. Make host+target builds possible in a single buildsystem by initializing
both the host and the target toolchain, specifying whether to find
dependencies in the host or the target, and specifying whether to build a
particular cmake-target for the host or for the target system. This does
not expose us to problems of clashes of cmake-target names for multiple
toolchains or problems of defining multiple per-toolchain make-targets
for a single cmake-target as all of those things remain impossible at
this step. This step requires some way to define such distinctions in
front-end CMakeLists.txt files. Possibly something like a toolchains()
command scoped to end with a endtoolchains() command.
 3. Make it possible to define multiple toolchains to build a single target
for. Still only two toolchains are possible (host+target), but now we can
define that a single cmake-target created with add_executable should be
built for both the host and the target. Consider moc for example, which
might make sense to build for both so that target-on-target builds (or
target-in-target-vm builds) can be done. In addition to step two, this
step requires solving the disabmiguation problems of cmake-targets and
other problems that come from using multiple toolchains from one
cmake-target definition.
 4. Make it possible to use N target toolchains. This takes advantage of the
solutions created in step 3. In addition to step 3, this step requires
deprecation of the undocumented CMAKE_TOOLCHAIN_FILE in favor of
something which can be a list, and it requires some way of attaching
names to toolchains. Projects using this have the disadvantage that there
is nothing but convention to standardise toolchain names. One project
might use RaspPi as a toolchain name in a CMakeLists.txt file, while
another uses RaspberryPi and yet another Raspbian. Qt has a similar issue
with device mkspec names.

 While the work in your branch has gotten
 impressively far, it also serves to demonstrate the inherent
 complexity of the proposed approach.  IMO it is not worth exploring
 that approach further.  Sorry.

 That reaction is not what I was hoping for. :)

I was surprised by Brad's answer as well.

 My branch makes a start mostly on steps 1 and 2 above, and to a small
 extent, step 4. 80% of the motivation and value of multiple toolchains comes
 from step 2, so I would happily truncate the other two as goals or leave
 them to future exporation.

+1
I do agree with that, I'm seldomly do cross-compiling but when I do
miss the native+target compilation I was used to when I was using
hand-written recursive makefile system 10+ year agos.

 I don't think an inappropriate amount of work or fundamental change to cmake
 is required to achieve step 2.

innappropriate amount heavily depends on who is doing the job but I guess
that the already proven workload given by Stephen to CMake speaks for itself.
I'm pretty sure he'll manage to do that.

The main issue would be, could it become a nightmare to maintain?

I did not manage to have so much time on the CMake front lately but
I'll try to follow and test Stephen work on that if it is going on.


--
Erk
L'élection n'est pas la démocratie -- http://www.le-message.org
--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] CPackRPM-protectATinFilename topic on stage

[Eric Noulard]

2013/5/21 Brad King brad.k...@kitware.com:
 Eric,

 This topic is on the stage but not in 'next'.  Now that 2.8.11
 is out please merge it for testing or drop it.

Sure, done:
To g...@cmake.org:stage/cmake.git
 - [deleted] CPackRPM-protectATinFilename

I did drop it because I have to redo-it since
f055c997a5ee186eb2f264cf4425148745ba6514
do have some overlap section with that one.

Sorry for the left over and my repeated absence on IRC for the CMake meeting.

--
Erk
L'élection n'est pas la démocratie -- http://www.le-message.org
--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] Strange test output of RogueResearch9

[Eric Noulard]

2013/5/11 Rolf Eike Beer e...@sf-mail.de:
 CTestTestMemcheckDummyBC
 (http://open.cdash.org/testDetails.php?test=189645609build=2901316)

 This fails because of this output:

 1/1 MemCheck #1: RunCMake .   Passed0.01 sec
 ctest(90028) malloc: protecting edges
 ctest(90028) malloc: enabling scribbling to detect mods to free blocks
 ctest(90028) malloc: enabling abort() on bad malloc or free
 ctest(90028) malloc: checks heap after 1th operation and each 100
 operations
 ctest(90028) malloc: will abort on heap corruption

Looks like this machine/setup is using Guard Malloc
see:
https://developer.apple.com/library/mac/documentation/performance/Conceptual/ManagingMemory/Articles/MallocDebug.html


 100% tests passed, 0 tests failed out of 1

 Has anyone an idea what is going on there?

This is just a wild guess since I have no Mac to test on at hand, right now.
--
Erk
L'élection n'est pas la démocratie -- http://www.le-message.org
--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] Strange test output of RogueResearch9

[Eric Noulard]

2013/5/11 Eric Noulard eric.noul...@gmail.com:
 2013/5/11 Rolf Eike Beer e...@sf-mail.de:
 CTestTestMemcheckDummyBC
 (http://open.cdash.org/testDetails.php?test=189645609build=2901316)

 This fails because of this output:

 1/1 MemCheck #1: RunCMake .   Passed0.01 sec
 ctest(90028) malloc: protecting edges
 ctest(90028) malloc: enabling scribbling to detect mods to free blocks
 ctest(90028) malloc: enabling abort() on bad malloc or free
 ctest(90028) malloc: checks heap after 1th operation and each 100
 operations
 ctest(90028) malloc: will abort on heap corruption

 Looks like this machine/setup is using Guard Malloc
 see:
 https://developer.apple.com/library/mac/documentation/performance/Conceptual/ManagingMemory/Articles/MallocDebug.html

Second may be valuable link:
http://stackoverflow.com/questions/9590350/xcode-scribble-guard-edges-and-guard-malloc
--

Powered by www.kitware.com

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

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

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

[cmake-developers] To be merged for next 2.8.11 rc?

[Eric Noulard]

Hi there,

I'm sorry I missed a lot of CMake on IRC meetings lately.
I won't be able to make it tonight again...

In any case I wish and think 2 staged topics should be merged-in for next
2.8.11 RC if
there is one left:

CPackRPM-avoidOwningSystemDirs
this one should solve a recurring bug report about system directories
being owned by CPack generated RPM.
The change should be safe because the only directories removed from
the generated RPM must be present on any RPM-based system.

CPackRPM-componentizedUserSpecFile
this one is for being able to use one user spec file by component.
This is safe too and probably concerns a very small amount of
advanced users.

I may merge CPackRPM-protectATinFilename
today as well but this one probably concerns a very small amount of users.
-- 
Erk
Le gouvernement représentatif n'est pas la démocratie --
http://www.le-message.org
--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] To be merged for next 2.8.11 rc?

[Eric Noulard]

2013/4/15 Brad King brad.k...@kitware.com

 On 04/15/2013 09:35 AM, Eric Noulard wrote:
  In any case I wish and think 2 staged topics should be merged-in for
 next 2.8.11 RC if
  there is one left:
 
  CPackRPM-avoidOwningSystemDirs
  this one should solve a recurring bug report about system directories
  being owned by CPack generated RPM.
  The change should be safe because the only directories removed from
  the generated RPM must be present on any RPM-based system.
 
  CPackRPM-componentizedUserSpecFile
  this one is for being able to use one user spec file by component.
  This is safe too and probably concerns a very small amount of
  advanced users.

 For each successive RC we have to be more strict about merging only
 fixes for regressions from previous releases and documentation updates.
 Any other kind of change can introduce new behavior changes that may
 invalidate results of RC testing already done by users.  If a new
 problem were to slip in it might not be caught by users (justifiably)

not willing to test every RC.


Yes I know that and you are right of course.

I guess I shall be more diligent and put things in
soon enough **before** any RC.
To be honest I should have fixed
CPackRPM-avoidOwningSystemDirs
long time ago a feel upset when a new bug related to this issue
appeared again... so I take time to fix it.



 Imagine diligently testing rc1 and concluding that it does not break
 your project.  Then the final release comes out and breaks it.  Now
 how motivated will you be to bother testing rc1 of the next release?


Not much, you are right again.

Then forget my request, this will wait 2.8.12.


-- 
Erk
Le gouvernement représentatif n'est pas la démocratie --
http://www.le-message.org
--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] Qt builds: module machine type 'x64' conflicts with target machine type 'X86'

[Eric Noulard]

2013/4/10 Stephen Kelly steve...@gmail.com

 Stephen Kelly wrote:

  So, how is the target 32bit/64bit determined? An option to cmake at cmake
  time?

 It seems to be determined by the generator:


 http://stackoverflow.com/questions/3785976/cmake-generate-visual-studio-2008-solution-for-win32-and-x64


I was about to say so.

Try
 git grep Win64

in the CMake source tree. You'll see that as well.


 I'll figure out a way to determine that in the ctest_testcase.prf file and
 set the 64 bit version.


check were CMAKE_GENERATOR variable is setup.
It is then used at line 73 of
https://qt.gitorious.org/qt/qtbase/blobs/HEAD/mkspecs/features/ctest_testcase.prf

cmake $$_PRO_FILE_PWD_ $$CMAKE_GENERATOR \

$$CMAKE_MODULE_DEFINES \
...




 Thanks,

 Steve.




 --

 Powered by www.kitware.com

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

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

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




-- 
Erk
Le gouvernement représentatif n'est pas la démocratie --
http://www.le-message.org
--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] Summer of code and Pascal

[Eric Noulard]

2013/2/12 Vittorio Giovara vittorio.giov...@gmail.com:
 Good to hear a positive response! Regarding your questions:


 What is the state of pascal compilers these days?
 Are they cross platform?
 Well GnuPascal is pretty much unsupported nowadays, although some binary
 distributions still exists, then there are a few close source program and
 finally there is Freepascal (www.freepascal.org) an opensource compiler
 written itself in pascal. Gpc and Fpc are indeed crossplatform, checkout the
 Freepascal home page for the full list of architectures. Hedgewars is using
 Freepascal to compile on Windows, Linux, Mac (ppc, x86, x86_64), Android and
 iOS (x86 and arm).

Some fast-readable page about Free Pascal (and Lazarus the free pascal IDE):
http://wiki.lazarus.freepascal.org/Overview_of_Free_Pascal_and_Lazarus

I do not use Pascal anymore but it was my very first programming language,
I'd rather not tell the year :-].

So even if Ohloh seems to say that CMake language is more active than Pascal
https://www.ohloh.net/languages/compare?measure=commitspercent=truel0=pascall1=cmakel3=-1commit=Update

would be nice to have Pascal support in CMake :-)

-- 
Erk
Le gouvernement représentatif n'est pas la démocratie --
http://www.le-message.org
--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] Fwd: Bug#699657: cmake: cmake -E touch truncates time

[Eric Noulard]

2013/2/4 Brad King brad.k...@kitware.com:
 On 02/04/2013 08:52 AM, Bill Hoffman wrote:
 # Touch the two files again
 $ touch file1 ; cmake -E touch file2 ; ls -l --full-time
 -rw-r- 1   0 2013-02-03 02:01:01.595819478 +0100 file1
 -rw-r- 1   0 2013-02-03 02:01:01.0 +0100 file2

 You introduced this here:

  http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5050706a

 From man utime:

  The utime() system call allows specification of timestamps with a resolution 
 of 1 second

On Linux one can use
utimensat(2) or futimens(2)
in order to have nanosec resolution.

I don't know since when it is supported and I don't know for other Unices.
Those functions are claimed to be in POSIX.1-2008.
-- 
Erk
Le gouvernement représentatif n'est pas la démocratie --
http://www.le-message.org
--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] Adding some generic section to the docs ?

[Eric Noulard]

2013/1/28 Brad King brad.k...@kitware.com:
 On 01/28/2013 10:37 AM, David Cole wrote:
 Sure, it's independent, but the lack of that feature is a very strong reason 
 why documentation HAS to be duplicated as things stand.

 Yes.

 Attacking that problem first, and THEN de-duplicating documentation seems 
 more logical to me.

 I'd much rather migrate to an existing markup language like
 reStructuredText than roll our own.  It will require additional
 tools to be installed to build the documentation, but reST is
 quite readable in source form anyway.

 We can keep the current generated documentation internal markup
 syntax and write a document formatter that produces .rst files
 in order to transition while still allowing existing documentation
 to work with command-line help output.

If we transition from current doc format to rst (or may be asciidoc
see later on)
I'd suggest we keep a way to get command line doc from this new source.

My best wish workflow would be to write all docs in relatively powerful
but lightweight markup (like rst of asciidoc) and then

1) build-time generate pure ascii doc that can be parsed and spitted-out
--help-  command line options like we have today.
We could parse rst/asciidoc directly but it may bring more
dependencies into CMake
source which doesn't seem a desirable property to me.

2) generate more beautiful doc (HTML, PDF/TEX/DOCBOOK)
with links, references etc... with sphinx or whatever tool we chose.

1] is very important to me because:

   A) you keep sort of builtin doc with no needed tool
   B) bash/zsh completion works very well because of the --help--list we
have for cmake, cpack, ctest

 With this approach we could add new documentation sections just
 by adding .rst files to the source tree.

I insist that all structured doc should be accessible from command
line without
being forced to open a web browser or pdf viewer etc

 Optionally we could use  something like Sphinx:

  http://sphinx-doc.org/

 to build full documentation from them.

Sorry no time to go on IRC for some weeks I'll try to catch-up next week.
-- 
Erk
Le gouvernement représentatif n'est pas la démocratie --
http://www.le-message.org
--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] CPACK_RESOURCE_FILE_LICENSE character encoding

[Eric Noulard]

2013/1/10 Nils Gladitz glad...@sci-vis.de:
 Is a license text file pointed to by CPACK_RESOURCE_FILE_LICENSE expected to
 have a specific encoding (ASCII, Latin1, UTF-8, ...)?

I don't know but I bet that some encoding may be accepted by some
CPack generator
and poorly handled by others.

CPACK_RESOURCE_FILE_LICENSE is used by:

STGZ
WIX
DragNDrop
PackageMaker
NSIS

WIX has documentation about that:
see cpack --help-variable CPACK_WIX_LICENSE_RTF

For the other generators I bet ASCII should work other encoding may work.

-- 
Erk
Le gouvernement représentatif n'est pas la démocratie --
http://www.le-message.org
--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] CPACK_RESOURCE_FILE_LICENSE character encoding

[Eric Noulard]

2013/1/10 Nils Gladitz glad...@sci-vis.de:
 I wrote the WiX part and am pondering how to support extended character sets
 without having to provide an extra RTF file.

Sorry I did not connect the dots.

 We've got an english license text file but our company address still
 contains a german umlaut.

Yes I'm french and we do have a bunch of non-ascii characters as well
(including french trema which is just like umlaut)
but we currently avoid those since none of them appear in our address :-]

 I could provide an RTF but I'd prefer not to have two license files.

I think the best way to go would be to try to go for utf-8 encoding which
is relatively widespread nowadays and goes into testing for each CPack
generator which currently use CPACK_RESOURCE_FILE_LICENSE.

Reading/writing utf-8 seems doable in plain C++ without
an example (untested) here: http://utfcpp.sourceforge.net/


-- 
Erk
Le gouvernement représentatif n'est pas la démocratie --
http://www.le-message.org
--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] [SOLVED]DESTDIR does not work correctly with install(FILES ... signature

[Eric Noulard]

2013/1/8 Alan W. Irwin ir...@beluga.phys.uvic.ca:
 On 2013-01-08 10:47+0100 Eric Noulard wrote:

 2013/1/8 Alan W. Irwin ir...@beluga.phys.uvic.ca:


 The rule should be simple as:

 You need to escape one time less than the number of cmake run occuring
 through the workflow path.
 In your case you have to escape once because install(CODE ...) is
 processed **by cmake**
 at Install time and you expect the evaluation to take place at that
 time.

 The may-be tricky part is when cmake (or derived cmake script engine
 is running)
 the running time of cmake tool suite may not be obvious and I tried
 to picture it in
 a tutorial (see excerpt attached to this mail)

 May be we can document common uses cases:

 install(CODE  -- one escape
 install(SCRIPT -- none

 add_custom_command/target -- one or two level escape depending on the
 arguments

 with various combination where you may configure_file
  1) yourself  before using install(SCRIPT ... -- my way of work
usually one escape level.

  2) through CPack like values used in CPACK_xxx variable which end up
   in some CPack template file which are processed first  at CMake-time
 and
   may be again at CPack-time. This one may lead to 2 level escape.


 Don't forget the example of code like this:

 set(CPACK_SOURCE_IGNORE_FILES
   #*#$
   ^${PROJECT_SOURCE_DIR}.*/.svn/
   

 I have been wrong about overcomplicating escapes in the past, but I
 think it this case, 4 levels of escapes are really necessary for these
 particular regex expressions.  Anyhow, I know this code works, but I
 don't know why!  Does your simple rule above explain this, and if so how?

In my mind this sequence is a two-level one
but you need four '\' because backslash **itself** need to be  escaped
at both level.

level 1 = when cmake runs
level 2 = when cpack runs and process CPACK_SOURCE_IGNORE_FILES.

in the end you need to get '\.' so you need \\. at level 1 output thus
. in the CMakeLists.txt

-- 
Erk
Le gouvernement représentatif n'est pas la démocratie --
http://www.le-message.org
--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] Limitations of IS_ABSOLUTE

[Eric Noulard]

2012/12/21 Alan W. Irwin ir...@beluga.phys.uvic.ca:
 My use case is I want to quickly test whether a data file that is external
 to the source tree exists or not.  So I naively tried to use if(IS_ABSOLUTE
 fullpathname) for this purpose, but all that tests at the current time is
 whether fullpathname starts with a slash or not.  It does not test
 whether fullpathname actually exists.

 To demonstrate this limitation use the following test script

 set(file /home/irwinx)
 if(IS_ABSOLUTE ${file})
   message(STATUS ${file} is absolute)
 else(IS_ABSOLUTE ${file})
   message(STATUS ${file} is not absolute)
 endif(IS_ABSOLUTE ${file})

 and run

 cmake -p test.cmake

 The result is

 -- /home/irwinx is absolute

 even though that absolute pathname does not exist.

 I suspect this behaviour is by design and not a bug, but in that case
 please change the documentation to say that IS_ABSOLUTE (unlike
 IS_SYMLINK and IS_DIRECTORY) just checks for a leading / regardless
 of whether the PATH exists or not so that users know the actual limits
 to the usefulness of IS_ABSOLUTE.

 I have brought this up because I think it is important to document the
 limitations of IS_ABSOLUTE when the existence of IS_SYMLINK and
 IS_DIRECTORY might lead the user to think there might be an existence
 test with IS_ABSOLUTE.

The doc may be clarified but my point of view is that
IS_SYMLINK and IS_DIRECTORY semantically requires the file to exists
while IS_ABSOLUTE does not.

Perhaps you should simply use:
if(IS_ABSOLUTE  ${file} AND EXISTS ${file})

  Obviously for my use case it does look like a
 reasonable alternative is to use file(GLOB...) followed by a check of
 the result variable to see if it is empty.  But implementation of an
 additional IF subcommand called IS_FILE which just checks for the
 existence of the specified file would do this in fewer lines and does

Precisely the purpose of
if(EXISTS ${file})

I think.

 seem to be a logical companion subcommand to IS_SYMLINK and IS_DIRECTORY.

Check this:
set(afile /home/irwinx)
set(anexistingpath /tmp/)

foreach (file ${anexistingpath} ${afile})
if(IS_ABSOLUTE ${file})
  message(STATUS ${file} is absolute)
else(IS_ABSOLUTE ${file})
  message(STATUS ${file} is not absolute)
endif(IS_ABSOLUTE ${file})

if(IS_ABSOLUTE ${file} AND EXISTS ${file})
  message(STATUS ${file} is an existing absolute path)
else()
  message(STATUS ${file} is not absolute or does not exists)
endif()
endforeach()

which gives:
$ cmake -P test-abs.cmake
-- /tmp/ is absolute
-- /tmp/ is an existing absolute path
-- /home/irwinx is absolute
-- /home/irwinx is not absolute or does not exists


-- 
Erk
Le gouvernement représentatif n'est pas la démocratie --
http://www.le-message.org
--

Powered by www.kitware.com

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

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

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

[cmake-developers] Documentation for CMAKE_*_FLAGS_* not homogenous

[Eric Noulard]

HI there,

While reading the builtin doc for
CMAKE_LANG_FLAGS_BUILD_TYPE
answering a questoin I was surprise by the fact that the documentation for
the CMAKE_*_FLAGS_*  variable is not very homogenous.

We currently have:
CMAKE_EXE_LINKER_FLAGS
CMAKE_EXE_LINKER_FLAGS_[CMAKE_BUILD_TYPE]
CMAKE_LANG_FLAGS_DEBUG
CMAKE_LANG_FLAGS_MINSIZEREL
CMAKE_LANG_FLAGS_RELEASE
CMAKE_LANG_FLAGS_RELWITHDEBINFO


Is there any reason we have
CMAKE_LANG_FLAGS_DEBUG
CMAKE_LANG_FLAGS_MINSIZEREL
CMAKE_LANG_FLAGS_RELEASE
CMAKE_LANG_FLAGS_RELWITHDEBINFO

instead of:
CMAKE_LANG_FLAGS_CMAKE_BUILD_TYPE

and why do we get:
CMAKE_EXE_LINKER_FLAGS_[CMAKE_BUILD_TYPE]

and not:
CMAKE_EXE_LINKER_FLAGS_CMAKE_BUILD_TYPE

then what is the relationship between
CMAKE_EXE_LINKER_FLAGS
and
CMAKE_EXE_LINKER_FLAGS_CMAKE_BUILD_TYPE

the builtin doc says nothing about it?

Last but not least we do not have documentation for
CMAKE_LANG_FLAGS

even if it is used by many bits of *.cmake files
and that Wiki
http://www.cmake.org/Wiki/CMake_Useful_Variables
says:
None (CMAKE_C_FLAGS or CMAKE_CXX_FLAGS used)

I think the documentations of all those vars may be improved:

1) use homogeneous naming
2) improve doc content and in particular explain their
links and reference appropriate properties

   COMPILE_FLAGS
   COMPILE_DEFINITIONS
   COMPILE_DEFINITIONS_CONFIG

 note again here that we have CONFIG and not
 CMAKE_BUILD_TYPE

I can work on a patch proposal but before doing that I'd like to
collect feedback/opinion.
Moreover if some of you want to fix that before I thikn about it go ahead :-]


-- 
Erk
Le gouvernement représentatif n'est pas la démocratie --
http://www.le-message.org
--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] rpm/deb component issue

[Eric Noulard]

2012/10/24 Clinton Stimpson clin...@elemtech.com:
 On Wednesday, October 24, 2012 11:59:52 AM Clinton Stimpson wrote:
 I have a problem with the rpm  deb cpack generators.

 I've set the following:
 set(CPACK_COMPONENTS_ALL_IN_ONE_PACKAGE 1)
 set(CPACK_DEB_COMPONENT_INSTALL 1)
 set(CPACK_RPM_COMPONENT_INSTALL 1)

 I get this implementation detail string ALL_COMPONENTS_IN_ONE being put in
 the package name (that is name, not the filename), so I end up with
 mypackage- ALL_COMPONENTS_IN_ONE.  To remove it, I do yum remove
 mypackage- ALL_COMPONENTS_IN_ONE.
 I would rather just have mypackage since that is the name I've specified.
 But I don't see a way to override it.

This is clearly a bug, I can't see any way to fix without a small patch.
Note that the DEB generator does not seem to suffer from this, is it?

When the xx.deb file is generated you can check it (without installing) using
dpkg-deb --info xx.deb
dpkg-deb --contents xx.deb
dpkg-deb --show xx.deb


 Does anyone have a suggested way for me to fix cmCPack*Generator.cxx and/or
 CPackDeb.cmake, CPackRPM.cmake?  This is the first time I've looked at
 modifying those particular files.

I think the best current workaround is to change CPackRPM.cmake.

 I have an idea that I'm comfortable with.  I'm effectively separating a
 variable into two, one for the component name, and another for the directory
 where it can be found.  For the ALL_COMPONENTS_IN_ONE mode, the directory can
 be ALL_COMPONENTS_IN_ONE/, but the component name empty.
 Let me know if you disagree.D

I agree and ended-up with the same patch (in CPackRPM.cmake).
You'll find my patch (against CMake master) proposal attached,
I'm not really sure it's the right final fix though.

Clint would you be kind enough to open a bug report for that please?

-- 
Erk
Le gouvernement représentatif n'est pas la démocratie --
http://www.le-message.org


0001-Fix-the-ALL_COMPONENTS_IN_ONE-spurious-suffix-with-C.patch
Description: Binary data
--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] rpm/deb component issue

[Eric Noulard]

2012/10/24 Clinton Stimpson clin...@elemtech.com:
 On Wednesday, October 24, 2012 09:27:38 PM Eric Noulard wrote:
 2012/10/24 Clinton Stimpson clin...@elemtech.com:
  On Wednesday, October 24, 2012 11:59:52 AM Clinton Stimpson wrote:
  I have a problem with the rpm  deb cpack generators.
 
  I've set the following:
  set(CPACK_COMPONENTS_ALL_IN_ONE_PACKAGE 1)
  set(CPACK_DEB_COMPONENT_INSTALL 1)
  set(CPACK_RPM_COMPONENT_INSTALL 1)
 
  I get this implementation detail string ALL_COMPONENTS_IN_ONE being put
  in the package name (that is name, not the filename), so I end up with
  mypackage- ALL_COMPONENTS_IN_ONE.  To remove it, I do yum remove
  mypackage- ALL_COMPONENTS_IN_ONE.
  I would rather just have mypackage since that is the name I've
  specified.
  But I don't see a way to override it.

 This is clearly a bug, I can't see any way to fix without a small patch.
 Note that the DEB generator does not seem to suffer from this, is it?

 When the xx.deb file is generated you can check it (without installing)
 using dpkg-deb --info xx.deb
 dpkg-deb --contents xx.deb
 dpkg-deb --show xx.deb

  Does anyone have a suggested way for me to fix cmCPack*Generator.cxx
  and/or
  CPackDeb.cmake, CPackRPM.cmake?  This is the first time I've looked at
  modifying those particular files.

 I think the best current workaround is to change CPackRPM.cmake.

  I have an idea that I'm comfortable with.  I'm effectively separating a
  variable into two, one for the component name, and another for the
  directory where it can be found.  For the ALL_COMPONENTS_IN_ONE mode, the
  directory can be ALL_COMPONENTS_IN_ONE/, but the component name empty.
  Let me know if you disagree.D

 I agree and ended-up with the same patch (in CPackRPM.cmake).
 You'll find my patch (against CMake master) proposal attached,
 I'm not really sure it's the right final fix though.

 Clint would you be kind enough to open a bug report for that please?


 The Deb generator suffers from the same problem.

Ok you are right my test was not done properly.

 Attached is my patch which is working fine for me.  Does it look OK?  I did 
 the
 approach of simplifying the .cmake files and putting the implementation 
 specific
 logic in the cmCPack*.cxx files.

Looks good, I'll give it a more thorough look  test tomorrow or the day after.

-- 
Erk
Le gouvernement représentatif n'est pas la démocratie --
http://www.le-message.org
--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] rpm/deb component issue

[Eric Noulard]

2012/10/24 Clinton Stimpson clin...@elemtech.com:

 Looks good, I'll give it a more thorough look  test tomorrow or the day
 after.

 Ok thanks.  I'll go ahead and put in on stage then.

 Also, when I run the tests, CPackComponents fails for me, and its because I
 don't have nsis installed on this Linux machine.  I'm looking at
 Tests/CMakeLists.txt and I don't see a way to turn off that test.  Only on
 Windows does it check the existence of nsis and disables the test.  Or am I
 looking at it wrong?

The
CTEST_RUN_CPackComponents is not a problem on linux.
and from my understanding this

if(NSIS_MAKENSIS_EXECUTABLE)
  set(CPackComponents_EXTRA_OPTIONS ${CPackComponents_EXTRA_OPTIONS}
-DCPACK_BINARY_NSIS:BOOL=ON)
endif()

should protect against trying to use NSIS generator on any platform.
because NSIS_MAKENSIS_EXECUTABLE
comes from:
find_program(NSIS_MAKENSIS_EXECUTABLE NAMES makensis ...)

which is not guarded by any platform specific test.

-- 
Erk
Le gouvernement représentatif n'est pas la démocratie --
http://www.le-message.org
--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] IRC meeting tomorrow ?

[Eric Noulard]

2012/10/14 Alexander Neundorf neund...@kde.org:
 Hi,

 this week I might have actually remembered it, but tomorrow I'm on business
 trip, so I won't have time to attend...

 So, I just merged AutomocFixDuplicatedFiles_13572 branch into next, which 
 fixes
 http://public.kitware.com/Bug/view.php?id=13572 , and which I'd still like to
 get into the 2.8.10 release.

I should be able to be there tomorrow but in any case I fixed 3 bugs which
were on the 2.8.10 roadmap which I think deserve to be included in 2.8.10.

I did test  merge to next today:

Fix-XXX_ON_ABSOLUTE_INSTALL_DESTINATION-handling | master=0 next=1
CPack-ArchiveGen-andDESTIR_ON | master=0 next=1
fix-some-CPackDoc-typos | master=0 next=1

I did move some other bugs to 2.8.11, due to lack of time and
too short forseen testing period.

See you tomorrow.
-- 
Erk
Le gouvernement représentatif n'est pas la démocratie --
http://www.le-message.org
--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] Sublime Text 2 / SublimeClang Generator

[Eric Noulard]

2012/10/12 Morné Chamberlain thefreeman...@gmail.com:
 On 12 October 2012 07:54, Eric Noulard eric.noul...@gmail.com wrote:

 Nevertheless why don't you provide us with your patch?
 That way we could at least try it?

 Sure, I can do that tonight or over the course of the weekend. What is
 the preferred way for me to provide you with the patch? Can I just
 send it as an attachment to this list, or should I send it somewhere
 specific? I could also put it on Github if that would be convenient?

Either way is fine I think Github is fine, just send another message
here in order to let us know.

If more CMake users/developers are interested send filing a bug
tracker feature request entry could be the next step.

The main issue may then be that if a new generator is to be added then
some tests  dashboard should be setup in order to ensure
it does not break in the future.

 I'm not a Sublime Text user so I don't even know how to create a
 Sublime Text project in the first place.

 On my first try I saw that syntax highlighting for CMake files are not 
 included
 in Sublime Text, is this part of your contribution as well?

 Sublime Text is very plug-in centric. There is a plug-in available
 that provides CMake syntax highlighting support. The easiest way to
 get started with plug-ins is to install the Package Control plug-in
 from here: http://wbond.net/sublime_packages/package_control.
 Pacakge Control manages a repository of available plug-ins and can
 list, install and remove plug-ins for you.

I'll have a look thanks.

[...]

-- 
Erk
Le gouvernement représentatif n'est pas la démocratie --
http://www.le-message.org
--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] patch for cmake that adds a new timestamp command

[Eric Noulard]

2012/9/27 David Cole david.c...@kitware.com:
 H. Good idea.

 Should we add a new command for this? Or should it be a sub-command of
 string( like RANDOM is?

 And... while we're at it, I've always thought we should add the
 ability to get the creation/modified/access times from a file via the
 CMake file command. If we allow getting the current time, we should
 leverage some of the same transformation-to-string code in the file
 command to get the various times associated with a file.

 What do other devs here think:
 New command or string sub-command for this functionality?

string sub-command for me, and agreed with Brad as well
for the namespace thing.

agreed with file(...) extension as well.

that said isn't the TIMESTAMP misleading?
shouldn't it be called DATE instead?



-- 
Erk
Le gouvernement représentatif n'est pas la démocratie --
http://www.le-message.org
--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] Questions on staged topic branches

[Eric Noulard]

2012/9/4 David Cole david.c...@kitware.com:
 If you are on the To line, please reply to this email, and answer
 the questions below:

 Brad and I have questions on these staged topic branches before we
 consider them for merging to 'master'.

 ##
 # Peter Kuemmel and Eric Noulard:
 #cpack-stripping | master=0 next=1

 This one should not be necessary. Can you tell us what problem it
 fixes? The only valid install path that should ever go under DESTDIR
 has to be an absolute path already anyways. So it will either start
 with a / already, or a $ because it begins with
 ${CMAKE_INSTALL_PREFIX}... so this change is unnecessary, and in
 fact harmful in the case where DESTDIR doesn't end with a / but the
 install rule does begin with ${CMAKE_INSTALL_PREFIX}. (Or are we
 misreading this somehow?)


 ##
 # Eric Noulard:
 #   CPackRPM_handleAttrDirectiveProperly | master=0 next=1

 The character set used in the REGEX here has errors in it: [A-Za-z\(\)-\,]

 1) The comma does not need to be escaped in this character set
 context, but \\ does if you mean to include the backslash character.

Only comma and hypen should be matched. Not backslash.

 2) The hyphen, if meant to be matched is not matched here, but used as
 a range separator from the \) to the \,

Right really sorry I overlooked that one.

 What's the intent of the change? To handle commas and hyphens, you
 would add ,- at the end of the existing character set. If more
 characters need to be matched, then add them, but keep the hyphen last
 or make it first or escape it in order to match it here.

I'll do that, but may be only this Week-End.

This corresponds to this bug
http://public.kitware.com/Bug/view.php?id=0013468
I did reopen it.

-- 
Erk
Le gouvernement représentatif n'est pas la démocratie --
http://www.le-message.org
--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] Proposal: An IRC dev meeting to chat about CMake stuff

[Eric Noulard]

2012/8/15 David Cole david.c...@kitware.com:
 This is a good idea.

 How many people would join in if we had a CMake meeting in #cmake IRC?

I'll try.
I just setup my IRC account (erk) and it seems to work.

 What would be the best day of week and time of day to have one?

Any daytime  between 9 AM up to 5 PM or after 6:30 PM.
I'll have some teaching probably on wednesday or thursday
but I don't have my next year schedule yet.

Anyway I cannot promise to be there everytime by I'll try to
be there.

 I know we have strong representation from Europe and East Coast US --
 anybody from time zones far away from those...?

I'm in France so GMT+1 / UTC+2.

-- 
Erk
Le gouvernement représentatif n'est pas la démocratie --
http://www.le-message.org
--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] Bug tracker: I need your help

[Eric Noulard]

2012/8/13 David Cole david.c...@kitware.com:
 Hi everybody,

 I need your help. In the next week, if you have time.

Done for me.
-- 
Erk
Le gouvernement représentatif n'est pas la démocratie --
http://www.le-message.org
--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] [CMake] Cross-compilation for windows on Darwin with nighlty build fails

[Eric Noulard]

2012/7/21 Claus Klein claus.kl...@arcormail.de:
 Hi Eric,

 would it be possible to change the CMakeFindBinUtils.cmake like my patch?
 With this this changes it works fine and it is faster too.

Alex is in charge of the bug you filed and has more knowledge than me
w.r.t. cross-compiling support in CMake so I'd rather let him examine
your patch.

 But I do not understand, why the second times, FIND_PROGRAM() fails?

I don't think it fails the second time the problem should be that
_CMAKE_TOOLCHAIN_LOCATION may not be set the first time
CMakeFindBinUtils.cmake is loaded.


 I have uploaded a log file to
 http://public.kitware.com/Bug/view.php?id=13379) which shows what happens
 without this patch.

Ok then you did all good,
Alex will pick it up.

-- 
Erk
Le gouvernement représentatif n'est pas la démocratie --
http://www.le-message.org
--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] trouble with running cpack --help during cmake step

[Eric Noulard]

2012/7/12 David Cole david.c...@kitware.com:

 I pushed this to 'next' the other day, but the test failures on dashmacmini3
 remain, so the latest commit is not having its intended effect.

 Back to Bill's original assertion:
 I am not sure how this works on a fresh build tree either as cpack won't
 even exist.

Yes Bill is right, I did check that but may be not thoroughly enough.
CPack/CMake etc... is installed at several place on my dev system
next time I'll check that no install cpack command may be used
during CMake fresh build.

 It must work on fresh build trees, because all of our Nightly dashboards
 work from fresh build trees. Since those work (even before this recent
 branch), there must be something else going on here.

May be.
The problem I see here generic CMake is bootstrapped
CPack is not, if it was we
could assume that CPack *is* available when CMake is.


 We're not going to merge this into 'master' until we get it right... I'll
 take a look at this tomorrow if you don't have time to spend on it right
 now, Eric.

Sorry for the delayed answer.
This is a good decision as usual.

I have not enough spare time right now and probably not much before July 20th...
I'm organizing a conference and this eats most of my time.

-- 
Erk
Le gouvernement représentatif n'est pas la démocratie --
http://www.le-message.org
--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] Weird behavior with spaces in ctest_configure

[Eric Noulard]

2012/7/9 David Cole david.c...@kitware.com:
 I'm wondering if we should fix the place where that warning is emitted as
 well. It seems like perhaps the variable it's complaining about is 
 CMAKE_BUILD_TYPE (with a leading space) and if we had some non-white-space
 bracketing characters around the variable name, the real problem would have
 been suggested more strongly by the output on the dashboard. Something like:

 CMake Warning:
   Manually-specified variables were not used by the project:

 [ CMAKE_BUILD_TYPE]

This would be nice and make it easier to catch some whitespace related error.
I Usually use  [] or  in order to exhibit such user defined values.

-- 
Erk
Le gouvernement représentatif n'est pas la démocratie --
http://www.le-message.org
--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] trouble with running cpack --help during cmake step

[Eric Noulard]

2012/7/2 Eric Noulard eric.noul...@gmail.com:
 2012/7/2 David Cole david.c...@kitware.com:


 Probably because of this:

   LIST(APPEND CMAKE_SYSTEM_PREFIX_PATH
 /sw# Fink
 /opt/local # MacPorts
 )

 from Darwin.cmake...

 OK could you try my proposal I just pushed on stage:

 To g...@cmake.org:stage/cmake.git
848f220..a8c659c  HEAD - DoNotInvokeCPackAtCMakeTime-forCMakeTests

 And of course you were right for the get the list at test time
 because at least
 the non-finding would have been consistent.

 I'll do that but probably not for 2.8.9.

David,
Bill,

Would you like me to push that to next  or would you have a look first?
It would definitely be better to have the **very same** way of checking
for tools (rpmbuild and dpkg) in Tests and/or cpack main
but like I said I won't have time to implement proper logic in CMake
Tests right now.


-- 
Erk
Le gouvernement représentatif n'est pas la démocratie --
http://www.le-message.org
--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] trouble with running cpack --help during cmake step

[Eric Noulard]

2012/7/2 David Cole david.c...@kitware.com:
 On Mon, Jul 2, 2012 at 11:58 AM, Eric Noulard eric.noul...@gmail.com wrote:
 2012/7/2 David Cole david.c...@kitware.com:

 On our dashmacmini3 dashboards, we're getting:

   DPKG_EXECUTABLE='/sw/bin/dpkg'

 It's found by find_program at CMake configure time, but cpack does not
 find this program (it's not in the PATH) at testing time.

 What should we do about this?

 I could just set DPKG_EXECUTABLE=OFF to circumvent the test on these 3
 dashboards for now... But I'd like a real fix for it. Seems like cpack
 should find it if CMake's find_program can find it.

 Yes I [apparently wrongly] supposed

 that
 cmSystemTools::FindProgram(dpkg)

 would find 'dpkg' iff:
 find_program(DPKG_EXECUTABLE NAMES dpkg)
 did find it...

 Why is the result of this two commands differents?
 Are there some env var that makes the behavior different?
 Or may be the configure environement is different from
 the test environment...


 --
 Erk
 Le gouvernement représentatif n'est pas la démocratie --
 http://www.le-message.org


 Probably because of this:

   LIST(APPEND CMAKE_SYSTEM_PREFIX_PATH
 /sw# Fink
 /opt/local # MacPorts
 )

 from Darwin.cmake...

OK could you try my proposal I just pushed on stage:

To g...@cmake.org:stage/cmake.git
   848f220..a8c659c  HEAD - DoNotInvokeCPackAtCMakeTime-forCMakeTests

And of course you were right for the get the list at test time
because at least
the non-finding would have been consistent.

I'll do that but probably not for 2.8.9.
-- 
Erk
Le gouvernement représentatif n'est pas la démocratie --
http://www.le-message.org
--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] trouble with running cpack --help during cmake step

[Eric Noulard]

2012/6/27 David Cole david.c...@kitware.com:
 On Tue, Jun 26, 2012 at 6:31 PM, David Cole david.c...@kitware.com wrote:
 On Tue, Jun 26, 2012 at 5:56 PM, Eric Noulard eric.noul...@gmail.com wrote:
 2012/6/26 Bill Hoffman bill.hoff...@kitware.com:
 So, this code here:

 2a34b579 Tests/CMakeLists.txt  (Eric NOULARD                  2012-03-30
 17:07:06 +0200  720)     # Analyze 'cpack --help' output for list of
 available generators:
 2a34b579 Tests/CMakeLists.txt  (Eric NOULARD                  2012-03-30
 17:07:06 +0200  721)     execute_process(COMMAND ${CMAKE_CPACK_COMMAND}
 --help


 The trouble is the cpack that is being tested is the one from the build
 tree.  If you have a very old CMake build tree, and you do a git pull and
 gets lots of new cmake code.  Then when you re-run cmake on the build tree,
 the cpack --help might crash.   I am not sure how this works on a fresh
 build tree either as cpack won't even exist.

 You are right this kind of tests may not be safely done at CMake time.
 I did that in order to avoid to replicate the code inside CPack factory
 (have a look at cmCPackDebGenerator::CanGenerate()
  and  cmCPackRPMGenerator::CanGenerate())
 which checks whether if a generator may be instantiated or not.
 This was done for conditionnally enabling RPM or DEB generator on MacOS
 see http://public.kitware.com/Bug/view.php?id=13064

 This is was mistake to do that in Tests/CMakeLists.txt.
 This should be harmless since it will probably only prevent RPM and DEB
 CPack tests to be run (ACTIVE_CPACK_GENERATORS will be empty)
 but this is a mistake.

 I shall implement proper CMake-time check in Tests/CMakeLists.txt.
 Unfortunately I may not be able to do that until sunday 1rst of July...

 Is this blocking 2.8.9 ?

 I'll try tomorrow night but I cannot ensure I'll have time to do it.

 Basically this would be something like:
 set(ACTIVE_CPACK_GENERATORS)
 then
 find_program(RPMBUILD_EXECUTABLE NAMES rpmbuild)
 if (RPMBUILD_EXECUTABLE)
   list(APPEND ACTIVE_CPACK_GENERATORS RPM)
 endif()

 find_program(DPKG_EXECUTABLE NAMES dpkg)
 if (DPKG_EXECUTABLE)
   list(APPEND ACTIVE_CPACK_GENERATORS DEB)
 endif()


 --
 Erk
 Le gouvernement représentatif n'est pas la démocratie --
 http://www.le-message.org
 --

 Powered by www.kitware.com

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

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

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


 It's not blocking 2.8.9 -- yet! -- but please get to it as soon as you
 can, and let us know when you've merged a fix to 'next'.

 Thanks,
 David



 A better alternative (I think) would be to run the same kind of code
 you are running now, but to do it at the correct time. i.e. -- execute
 the code that is currently running at cmake configure time via a
 script that gets invoked when the test is run.

This is true but it makes the CPack testing not so obvious.
Since the current code was used to create tests so we get a
chicken and eggs problem.

currently after (initial) configuration  I can do:
ctest -R RPM -N

and get the list of tests?
What filtering capability would I get if the test itself is generating subtest?

The issue here is that CMake is assumed to be there when CMake itself
is built ( because CMake can/must be boostrapped) whereas CPack may
not be there when it is built.

A possible solution would be to separate the definition of all the
CPack related tests
in order to define them when we know that CPack has been built.

 Then you *can* reliably
 use the built cpack to see what generators it says it supports, and
 use those as the list of generators to test.

In order to get this fix fast enough I did not implement this solution now,
I'll think more about.
The current fix (in next):
Merge topic 'DoNotInvokeCPackAtCMakeTime-forCMakeTests' into next

848f220 Do not run cpack at CMake time it is not available.

just checks for rpmbuild and dpkg availability.

-- 
Erk
Le gouvernement représentatif n'est pas la démocratie --
http://www.le-message.org
--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] trouble with running cpack --help during cmake step

[Eric Noulard]

2012/6/26 Bill Hoffman bill.hoff...@kitware.com:
 So, this code here:

 2a34b579 Tests/CMakeLists.txt  (Eric NOULARD                  2012-03-30
 17:07:06 +0200  720)     # Analyze 'cpack --help' output for list of
 available generators:
 2a34b579 Tests/CMakeLists.txt  (Eric NOULARD                  2012-03-30
 17:07:06 +0200  721)     execute_process(COMMAND ${CMAKE_CPACK_COMMAND}
 --help


 The trouble is the cpack that is being tested is the one from the build
 tree.  If you have a very old CMake build tree, and you do a git pull and
 gets lots of new cmake code.  Then when you re-run cmake on the build tree,
 the cpack --help might crash.   I am not sure how this works on a fresh
 build tree either as cpack won't even exist.

You are right this kind of tests may not be safely done at CMake time.
I did that in order to avoid to replicate the code inside CPack factory
(have a look at cmCPackDebGenerator::CanGenerate()
 and  cmCPackRPMGenerator::CanGenerate())
which checks whether if a generator may be instantiated or not.
This was done for conditionnally enabling RPM or DEB generator on MacOS
see http://public.kitware.com/Bug/view.php?id=13064

This is was mistake to do that in Tests/CMakeLists.txt.
This should be harmless since it will probably only prevent RPM and DEB
CPack tests to be run (ACTIVE_CPACK_GENERATORS will be empty)
but this is a mistake.

I shall implement proper CMake-time check in Tests/CMakeLists.txt.
Unfortunately I may not be able to do that until sunday 1rst of July...

Is this blocking 2.8.9 ?

I'll try tomorrow night but I cannot ensure I'll have time to do it.

Basically this would be something like:
set(ACTIVE_CPACK_GENERATORS)
then
find_program(RPMBUILD_EXECUTABLE NAMES rpmbuild)
if (RPMBUILD_EXECUTABLE)
   list(APPEND ACTIVE_CPACK_GENERATORS RPM)
endif()

find_program(DPKG_EXECUTABLE NAMES dpkg)
if (DPKG_EXECUTABLE)
   list(APPEND ACTIVE_CPACK_GENERATORS DEB)
endif()


-- 
Erk
Le gouvernement représentatif n'est pas la démocratie --
http://www.le-message.org
--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] current hugin not compilable ATM

[Eric Noulard]

2012/6/17 Kornel Benko kor...@lyx.org:


 Maybe forgotten to push Image.cpp and Image.h?

Looks like this mail end-up in the wrong list?
This is cmke-developer ML?
Looks like it belongs to Hugin ML?
Or did I miss something?


 ...

 [ 81%] Building CXX object
 src/hugin_cpfind/localfeatures/CMakeFiles/keypoints.dir/keypoints.cpp.o

 /usr/src/hugin/hugin_hg/src/hugin_cpfind/localfeatures/keypoints.cpp: In
 function ‘bool DetectKeypoints(const string, bool, double,
 lfeat::KeyPointPtr, bool, int, int, int, lfeat::KeypointWriter)’:

 /usr/src/hugin/hugin_hg/src/hugin_cpfind/localfeatures/keypoints.cpp:188:86:
 error: no matching function for call to
 ‘lfeat::Image::init(vigra::BasicImagedouble::iterator, int, int)’

 /usr/src/hugin/hugin_hg/src/hugin_cpfind/localfeatures/keypoints.cpp:188:86:
 note: candidate is:

 /usr/src/hugin/hugin_hg/src/hugin_cpfind/./localfeatures/Image.h:41:10:
 note: void lfeat::Image::init(vigra::DImage)

 /usr/src/hugin/hugin_hg/src/hugin_cpfind/./localfeatures/Image.h:41:10:
 note: candidate expects 1 argument, 3 provided

 make[2]: ***
 [src/hugin_cpfind/localfeatures/CMakeFiles/keypoints.dir/keypoints.cpp.o]
 Error 1

 make[1]: *** [src/hugin_cpfind/localfeatures/CMakeFiles/keypoints.dir/all]
 Error 2

 make: *** [all] Error 2

 ...



 Kornel




 --

 Powered by www.kitware.com

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

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

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



-- 
Erk
Le gouvernement représentatif n'est pas la démocratie --
http://www.le-message.org
--

Powered by www.kitware.com

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

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

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

[cmake-developers] CMAKE_EXPORT_COMPILE_COMMANDS undocumented

[Eric Noulard]

Hi all,

The CMAKE_EXPORT_COMPILE_COMMANDS is not documented
i.e. not available when using
cmake --help-variable CMAKE_EXPORT_COMPILE_COMMANDS

is it intentional because it is to be considered 'internal' to CMake
shall it be added?
-- 
Erk
Le gouvernement représentatif n'est pas la démocratie --
http://www.le-message.org
--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] Welcome to June, time for the next release candidate

[Eric Noulard]

2012/6/5 Kornel Benko kor...@lyx.org:
 Am Montag, 4. Juni 2012 um 17:13:26, schrieb David Cole
 david.c...@kitware.com

 We are preparing to build CMake 2.8.9, release candidate one, in the next

 few days (or possibly as late as next week).



 Is there any pending/outstanding work that anybody thinks is critical for

 inclusion in CMake 2.8.9?



 (I don't want to trigger a flurry of activity by sending this out... but I

 suppose it's better to have it before we decide to cut rc1 than after. ;-)





 Thanks,

 David



 There is still the problem that created debian packages are not working with

 dpkg.



 System: ubuntu 12.04, 64 bit.

 Cmake: created with -DCMAKE_USE_SYSTEM_LIBARCHIVE:BOOL=ON



 The following list of commands:



 # make package # create xyzz.deb

 # ar rv xyzz.deb data.tar.gz

 # tar ztvf data.tgz /dev/null

 tar: Ignoring unknown extended header keyword
 `SCHILY.fflags'

 tar: Ignoring unknown extended header keyword
 `SCHILY.fflags'

 tar: Ignoring unknown extended header keyword
 `SCHILY.fflags'

 tar: Ignoring unknown extended header keyword
 `SCHILY.fflags'



 I already proposed a patch in the users list (using
 archive_write_set_format_gnutar()

Discussion is in this thread:
http://www.cmake.org/pipermail/cmake/2012-May/050483.html


 instead of archive_write_set_format_pax_restricted() in file
 Source/cmArchiveWrite.cxx)

 which make things work OK on this system.

Hi Kornel,
Like I said in the previous thread, we simply cannot switch to gnutar, it will
potentially break many other systems.

Moreover when you compiled the very same CMake using the shipped-in cmlibarchive
you didn't get the error.
So the issue is an interaction between system provided libarchive and CMake,
did try to contact Ubuntu packager about that?

-- 
Erk
Le gouvernement représentatif n'est pas la démocratie --
http://www.le-message.org
--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] Welcome to June, time for the next release candidate

[Eric Noulard]

2012/6/4 David Cole david.c...@kitware.com:
 We are preparing to build CMake 2.8.9, release candidate one, in the next
 few days (or possibly as late as next week).

 Is there any pending/outstanding work that anybody thinks is critical for
 inclusion in CMake 2.8.9?

Critical, not really but that one has been waiting in my stack for a long time:
(in fact longer than the initial bug report)
http://public.kitware.com/Bug/view.php?id=12997

I may not be able to finish (un-pushed) work before next week
but if I have a chance to push the first set of clean-up that would be great.


 (I don't want to trigger a flurry of activity by sending this out... but I
 suppose it's better to have it before we decide to cut rc1 than after. ;-)

-- 
Erk
Le gouvernement représentatif n'est pas la démocratie --
http://www.le-message.org
--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] Welcome to June, time for the next release candidate

[Eric Noulard]

2012/6/4 David Cole david.c...@kitware.com:
 We are preparing to build CMake 2.8.9, release candidate one, in the next
 few days (or possibly as late as next week).

 Is there any pending/outstanding work that anybody thinks is critical for
 inclusion in CMake 2.8.9?

Could you take this one:

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

 (I don't want to trigger a flurry of activity by sending this out... but I
 suppose it's better to have it before we decide to cut rc1 than after. ;-)

-- 
Erk
Le gouvernement représentatif n'est pas la démocratie --
http://www.le-message.org
--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] Github pull request for CPack NSIS generator

[Eric Noulard]

2012/5/25 Brad King brad.k...@kitware.com:
 On 05/25/2012 09:38 AM, Eric Noulard wrote:
 2012/5/25 Brad King brad.k...@kitware.com:
  https://github.com/Kitware/CMake/pull/5

 I'm not a too good NSIS tester since my usual system is Linux :-)

 I do cross-test NSIS (cross compile win32 on Linux + NSIS) but
 I seldom boot Windows...

 However, I will review (read) the patch.

 Thanks.  It conflicts with some of your other changes so I jumped
 to the conclusion that you've worked with the relevant code.
 Perhaps that was only in your documentation sweep though.

Just reviewed the patch.
It's ok and harmless, it is fixing error message and adds documentation.
but you are right it may not be applied as-is because of the
CPack documentation update.

The only missing part was the log error message fix.
I did create a branch (based on current) master which contains
the fix, I did some basic testing but I may be you want
to test it yourself before I merge it?

stage/cpack-nsis-menu-links-adapted

Like I said it does not need in depth testing (besides an actual NSIS
packaging run)
because it only  change a warning message
(the documentation block part was already up to date on current master)

-- 
Erk
Le gouvernement représentatif n'est pas la démocratie --
http://www.le-message.org
--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] Github pull request for CPack NSIS generator

[Eric Noulard]

2012/5/25 Brad King brad.k...@kitware.com:
 Eric,

 Please take a look at this request:

  https://github.com/Kitware/CMake/pull/5

 Only the first commit is relevant, the rest are merges from upstream.
 You can fetch the relevant part of the branch like this:

  $ git fetch git://github.com/Fraser999/CMake.git master
  $ git checkout -b cpack-nsis-menu-links 365d4154

I'll have a look in the forthcoming day
even if I'm not a too good NSIS tester since my usual system is Linux :-)

I do cross-test NSIS (cross compile win32 on Linux + NSIS) but
I seldom boot Windows...

However, I will review (read) the patch.

-- 
Erk
Le gouvernement représentatif n'est pas la démocratie --
http://www.le-message.org
--

Powered by www.kitware.com

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

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

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

[cmake-developers] Some dashboard warnings and errors

[Eric Noulard]

Hi all,

My merge of stage/CPack-activateRPM-DEB-onMacOS to next yesterday raised
some warning on this dashboard:
http://open.cdash.org/viewBuildError.php?type=1buildid=2293803

the warning are right, the static method call *is always true* but
shall I really try to avoid such warning?
The always true may become some day not always true but I wanted to have
CPackGeneratorFactory be coded in a uniform way.

What shall I do with that?

Then the same set of commits may be responsible for that:
http://open.cdash.org/buildSummary.php?buildid=2294180

but I can't find a reason for all 192 failing tests, can anyone enlight me?
The only thing I see is

[flag] ArgumentExpansion   Failed  Passed  900ms   Completed (SEGFAULT)

I cannot imagine why my change would generate such SEGFAULT series ...
-- 
Erk
Le gouvernement représentatif n'est pas la démocratie --
http://www.le-message.org
--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] Some dashboard warnings and errors

[Eric Noulard]

2012/5/21 Brad King brad.k...@kitware.com:
 On 05/21/2012 03:50 AM, Eric Noulard wrote:
 My merge of stage/CPack-activateRPM-DEB-onMacOS to next yesterday raised
 some warning on this dashboard:
 http://open.cdash.org/viewBuildError.php?type=1buildid=2293803

 the warning are right, the static method call *is always true* but
 shall I really try to avoid such warning?
 The always true may become some day not always true but I wanted to have
 CPackGeneratorFactory be coded in a uniform way.

 What shall I do with that?

 Try this:

 diff --git a/Source/CPack/cmCPackGeneratorFactory.cxx 
 b/Source/CPack/cmCPackGeneratorFactory.cxx
 index dbfdbbc..37ff460 100644
 --- a/Source/CPack/cmCPackGeneratorFactory.cxx
 +++ b/Source/CPack/cmCPackGeneratorFactory.cxx
 @@ -40,6 +40,10 @@

  #include cmCPackLog.h

 +#if defined(__BORLANDC__)
 +# pragma warn -8008 /* condition is always true */
 +#endif
 +
  //--
  cmCPackGeneratorFactory::cmCPackGeneratorFactory()
  {

Ok just pushed that:
Merge topic 'CPack-activateRPM-DEB-onMacOS' into next

801ea70 Calm down Borland compiler warning about always true

 Then the same set of commits may be responsible for that:
 http://open.cdash.org/buildSummary.php?buildid=2294180

 but I can't find a reason for all 192 failing tests, can anyone enlight me?
 The only thing I see is

 [flag] ArgumentExpansion     Failed  Passed  900ms   Completed (SEGFAULT)

 I cannot imagine why my change would generate such SEGFAULT series ...

 The same machine passed its nightly build so something local must have
 gone wrong for the continuous.  I don't think it's related to your change.

ok then.

Thanks Brad.
-- 
Erk
Le gouvernement représentatif n'est pas la démocratie --
http://www.le-message.org
--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] Do not take CPackNSIS-warnDESTDIRandABSOLUTE yet

[Eric Noulard]

2012/5/17 Eric Noulard eric.noul...@gmail.com:
 Hi there,

 I did merge CPackNSIS-warnDESTDIRandABSOLUTE to next may be a little early.
 It is functional and do not introduce any regression but
 I think I should make some renaming in order to be more consistent.

 The variables:
 CPACK_WARN_ON_ABSOLUTE_INSTALL_DESTINATION
 CPACK_ERROR_ON_ABSOLUTE_INSTALL_DESTINATION
 and older one (not coming from this patch)
 CPACK_ABSOLUTE_DESTINATION_FILES

 are defined in generated cmake_install.cmake files.
 So they may be ill-named and should be renamed with a
 CMAKE_ prefix because they can be used without CPack.

 I'll then make CPack use/monitor  the CMAKE_ renamed variable
 and forward definition to/from CPACK_xxx ones.

 I'll do that later today and re-push+merge to next today.
 In the meantime better not merging current
 CPackNSIS-warnDESTDIRandABSOLUTE to master.


Today has been pushed a little forward...
Merge topic 'CPackNSIS-warnDESTDIRandABSOLUTE' into next
4986d52 Use CPACK_xxx and CMAKE_xxx in a consistent way.

I think, the branch CPackNSIS-warnDESTDIRandABSOLUTE may be considered
to be merged to master.

-- 
Erk
Le gouvernement représentatif n'est pas la démocratie --
http://www.le-message.org
--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] Making the default install component name configurable

[Eric Noulard]

2012/5/14 Alexander Neundorf neund...@kde.org:
 On Monday 14 May 2012, Brad King wrote:

 On 5/13/2012 2:15 PM, Alexander Neundorf wrote:

  the CMAKE_DEFAULT_INSTALL_COMPONENT_NAME variable is still in

  Unspecified, so this is still the default.



 I'd rather the name be



 CMAKE_INSTALL_DEFAULT_COMPONENT_NAME



 to keep the CMAKE_INSTALL_ prefix for variables affecting

 installation (along with CMAKE_INSTALL_PREFIX).

 Or shorter CMAKE_INSTALL_DEFAULT_COMPONENT ?

 But that sounds more like a boolean switch...

Yes agreed.
I'd rather go for
CMAKE_INSTALL_DEFAULT_COMPONENT_NAME

or may be
CMAKE_INSTALL_UNSPECIFIED_COMPONENT_NAME

and in any case I agree with Brad concerning the CMAKE_INSTALL_ prefix.

-- 
Erk
Le gouvernement représentatif n'est pas la démocratie --
http://www.le-message.org
--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] Test suite broken if PackageMaker not installed in default location

[Eric Noulard]

2012/5/1 David Cole david.c...@kitware.com:

 That's what I saw actually, but mine was not in the list. Setting
 CPACK_INSTALLER_PROGRAM as in line 390 does not help because the it is
 not transfered to the test project.

 Is there a robust way to tell cmake where is installed PackageMaker if
 it is not installed in one of the searched paths?


 Not yet, but we can definitely fix that moving forward.

Some CPack generators assumes some commands are found.
RPM assumes rpmbuild
NSIS assumes makensis
PackageMaker assumes PackageMaker

simply testing the system (APPLE, LINUX, Windows...) may not be enough
or even worse (or better depending on your opinion), some people
may want to uses some unusual packager on particular system
like using DEB or RPM on MacOS:
see http://public.kitware.com/Bug/view.php?id=13064

Some tests in CMake source tree already checks that the required tool
is found **before** adding the test but it causes code duplication.
(because users may have to do the very same check in their project)
so may be we need something like:

cpack -G GEN --check-only that would verify that the GEN
CPack generator may be run?

Concerning  a way to make CPACK_INSTALLER_PROGRAM be
transmitted to the test, it's possible if we define a CPack Project Config file
template for this test and forward the definition of CPACK_INSTALLER_PROGRAM
done at CMake time (using configure_file on the CPack project config
file) to CPack time.


-- 
Erk
Le gouvernement représentatif n'est pas la démocratie --
http://www.le-message.org
--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] bug in cmake 2.8.8?

[Eric Noulard]

2012/4/26 Brad King brad.k...@kitware.com:
 On 4/26/2012 8:25 AM, Bill Hoffman wrote:

 Anyone have any ideas what this bug is from:

 https://bbs.archlinux.org/viewtopic.php?pid=1092231


 Related:

  https://bugs.launchpad.net/compiz-plugins-main/+bug/987805

 I don't know how FindCompiz.cmake ends up in the CMake modules
 directory on their system:

  $ ls /usr/share/cmake-2.8/Modules | grep FindCompiz
  FindCompiz.cmake
  FindCompizConfig.cmake

 It's not in our distribution AFAIK.

Looks like it comes from compiz itself.
http://gitweb.compiz.org/?p=compiz/core;a=tree;f=cmake;h=d0cef0f89417b3d9fe9b68f88c4312d44f161d3c;hb=HEAD
(see http://wiki.compiz.org/C%2B%2BCompiling as well)

But normally those files shouldn't end-up in CMake install dir:
http://gitweb.compiz.org/?p=compiz/core;a=blob;f=cmake/CMakeLists.txt;h=5c7b1f801e49c6236253b9462c8f3fa3555db206;hb=HEAD


-- 
Erk
Le gouvernement représentatif n'est pas la démocratie --
http://www.le-message.org
--

Powered by www.kitware.com

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

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

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

[cmake-developers] Review request: bash completion enhancement:

[Eric Noulard]

Hi all,

I just push a stage/EnhanceBash-completion-part1
which includes the contribution from Igor Murzov
http://cmake.org/Bug/view.php?id=13056

Previous completion files were done by me, those from Igor are far
better than mine.
I tried to adapt Igor's proposal to the current CMake source layout and put
the files in Docs/ subdir.

Before that the completion file (as any other file found in Docs) were
not installed at all.
I think it's better to install those file such that Distro packager
can include them.

I didn't pushed to next because I didn't know why vim file or emacs
highlighting files
found in the same directory are not installed.

Could someone review the patch before I merge to next?

As stated in http://cmake.org/Bug/view.php?id=13056
if you use a distribution with bash_completion  2.0 you need to either
source cmake/cpack/ctest from the shell or
install symbolic links from share/completions/c* to /etc/bash_completion.d/

(and start a new bash).
-- 
Erk
Le gouvernement représentatif n'est pas la démocratie --
http://www.le-message.org
--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] [CMake 0013150]: Manual page formatting fixes

[Eric Noulard]

2012/4/20 Rolf Eike Beer e...@sf-mail.de:
 The attached is a patch with manual page formatting fixes for 2.8.8. Issues
 were detected by Lintian, Debian Q/A tool.

 This always happens after a new version, no?

Yes I think that since Modestas is the maintainer of the cmake debian package
http://packages.debian.org/wheezy/cmake
he discovers the problem when preparing the cmake package for sid.

Is it the case Modestas?

 Can we get that tool as part of
 the build process somehow so we get that on the nightly builds?

You are right, and I was thinking of this.
I think we can easily do that if we add a CPackDeb test
which build cmake .deb package using CPack DEB.
Then run lintian (if found) on the package.

Unfortunately we will get more warning than wanted because
CPackDeb does not [yet] produce package which are
lintian-OK, but we could at least grep the error on the manpage.

Initially we could just run
lintian --check-part manpages cmake-x.deb

and error concerning manpages.


-- 
Erk
Le gouvernement représentatif n'est pas la démocratie --
http://www.le-message.org
--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] New OBJECT library feature

[Eric Noulard]

2012/3/19 Brad King brad.k...@kitware.com:
 Hi Folks,

 I've just pushed a new 'object-library' topic and merged to 'next'
 for testing.  David Cole and I have been working on it for a couple
 of weeks.  The following documentation added to the add_library
 command explains:

 --
  The signature

   add_library(name OBJECT src...)

  creates a special object library target.  An object library compiles
  source files but does not archive or link their object files into a
  library.  Instead other targets created by add_library or
  add_executable may reference the objects using an expression of the
  form $TARGET_OBJECTS:objlib as a source, where objlib is the
  object library name.  For example:

   add_library(... $TARGET_OBJECTS:objlib ...)
   add_executable(... $TARGET_OBJECTS:objlib ...)

  will include objlib's object files in a library and an executable
  along with those compiled from their own sources.  Object libraries
  may contain only sources (and headers) that compile to object files.
  They may contain custom commands generating such sources, but not
  PRE_BUILD, PRE_LINK, or POST_BUILD commands.  Object libraries cannot
  be imported, exported, installed, or linked.

That's a great feature.
This would be useful for cross-compiled  target.

Is there a feature that could guarantee the order of appearance of
those objects / object library on the link line generated for
add_executable ?

By the way why wouldn't you authorize
target_link_libraries(exetarget objlibname) ?


 --

 Many of the documented restrictions are temporary until meaningful
 behavior can be defined and implemented for them in a future version.
 It is easiest to simply disallow all but the basic use case for now.

Ok this answers my previous question.

 This feature plays a role similar to autotools convenience libraries
 but works with all toolchains and under VS and Xcode.  We've updated
 all primary generators to support object libraries including the Ninja
 generator.  Until this goes into master watch out for conflicts when
 making changes to the other generators.


I'll test the feature.
-- 
Erk
Le gouvernement représentatif n'est pas la démocratie --
http://www.le-message.org
--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] New OBJECT library feature

[Eric Noulard]

2012/3/19 Brad King brad.k...@kitware.com:
 On 3/19/2012 1:56 PM, Eric Noulard wrote:

 That's a great feature.


 Thanks.


 Is there a feature that could guarantee the order of appearance of
 those objects / object library on the link line generated for
 add_executable ?

 Currently no order is guaranteed other than that all the object files
 from directly compiled sources, external objects, and object libraries
 will all come before any _linked_ libraries.  I'm not sure whether it
 is even possible to guarantee an order in all our target build systems.

 Can you enumerate use cases when the order of objects matters?  Unlike
 static libraries *all* objects will be included.  If there are duplicate
 symbols it is an error.  If there are not duplicate symbols then how
 does order matter?

I have to dig into an exotic build system I converted from makefile to CMake
in order to fully understand why. As far as I remember it was
mandatory but I cannot
remember the reason.

This use cases I do compile object using add_library and a single
file using a custom command because the final link step
(done with a custom command as well)  requires this last object object file
to be given first on the command line.

The custom command likn step looks like:
COMMAND ${CMAKE_LINKER} --oformat binary -Ttext ${BM_IMAGE_ADDRESS}
-melf_i386 -e _start -o ${BM_APPNAME}.bin ${BM_STARTUPOBJ}
--start-group $TARGET_LINKER_FILE:system $TARGET_LINKER_FILE:xc
$TARGET_LINKER_FILE:${BM_APPNAME} --end-group ${BM_LDSCRIPT}

${BM_STARTUPOBJ} is the specific object file compiled on its own using
custom command.

Now that I think about it, before that I was forced to create a custom
command in order
to compile the file ('with the same option as the one compiled by add_library)
but now I will be able to build an OBJECT library containing a single file
and refer to it using $TARGET_OBJECTS:objlib which is perfectly fine for
ensuring the ordering I may need for the link step.

-- 
Erk
Le gouvernement représentatif n'est pas la démocratie --
http://www.le-message.org
--

Powered by www.kitware.com

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

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

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