Re: [CMake] installing source (or object) files

[Kris Thielemans]

Hi

 

I haven't had any replies to my message below, hopefully because it was sent
at the wrong time of year. So I'm reposting, but with some  clarifications.

 

I wrote the message about include_flags only. I've currently solved this by
adding a variable 

 

   Set(STIR_INCLUDE_DIRS blabla)

 

in my STIRConfig.cmake.in (which is at

https://github.com/UCL/UCL-STIR/blob/master/src/cmake/STIRConfig.cmake.in)

 

and tell the user of the library that they have to do

 

include_directories(${STIR_INCLUDE_DIRS})

 

This works but only for include directories, not for other compiler flags.
I've currently solved that by putting all (most?) of these in a
STIRConfig.h.in.

 

I don't particularly like the include_directories solution however. I
believe CMake's eport facility is trying to get away from this. Indeed, for
the library, its include path (and other compilation flags) get
automatically exported, so the user doesn't have to do anything else than
target_link_libraries to inherit all necessary flags.

 

Also, my current solution relies on exporting the .cxx. It seems safer to
export the object file as that is guaranteed to have been compiled with the
correct flags, but I don't know how to do that.

 

I hope my message below makes more sense now.

 

Thanks

 

Kris

From: Kris Thielemans
Sent: 27 December 2016 16:12
To: cmake@cmake.org
Subject: installing source (or object) files

 

Hi all

 

I have a non-standard set-up where I have a library that needs to be linked
together with some extra source files that contain "registries"). So in my
CMakeLists.txt I use

 

Add_executable(wonderful_program wonderful_program.cxx registry.cxx)

target_link_libraries(wonderful_program mylib)

 

registry.cxx needs to be compiled with some of my include files.

 

For that, I added

 

include_directories("${PROJECT_SOURCE_DIR}/src/include")

 

I guess I could just as well have added

 

SET_PROPERTY(SOURCE registry.cxx PROPERTY COMPILE_FLAG
"-I${STIR_INCLUDE_DIR}")

 

 

This works fine, but now I want to export my library (relocatable). I have
created a config file etc, added mylib as an install target, installed the
include files etc. All of that works great for the library. However, I have
no idea how to install registry.cxx. I could just 

 

INSTALL(FILES registry.cxx .)

 

However, that doesn't copy the properties of the source files anywhere. In
particular, it means that a "client" doesn't know what compilation flags to
use.

 

Any ideas?

 

Best wishes for 2017!

 

Kris

 

PS: The reason that I need registry.cxx is that it contains some variables
that have a funky constructor that initialises some registries somewhere.

PS: Full source code is at https://github.com/UCL/STIR

-- 

Powered by www.kitware.com

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

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

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

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

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

[Cmake-commits] CMake branch, master, updated. v3.7.2-1130-gf5fae34

[Kitware Robot]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, master has been updated
   via  f5fae345e4a0f9f54b69424552f7d85aa85ba907 (commit)
  from  fe8e00f6b91d7e8614af5a5ffb2ab68775b06e1c (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f5fae345e4a0f9f54b69424552f7d85aa85ba907
commit f5fae345e4a0f9f54b69424552f7d85aa85ba907
Author: Kitware Robot <kwro...@kitware.com>
AuthorDate: Thu Jan 19 00:01:05 2017 -0500
Commit: Kitware Robot <kwro...@kitware.com>
CommitDate: Thu Jan 19 00:01:05 2017 -0500

CMake Nightly Date Stamp

diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index 4a74d4c..ce72bba 100644
--- a/Source/CMakeVersion.cmake
+++ b/Source/CMakeVersion.cmake
@@ -1,5 +1,5 @@
 # CMake version number components.
 set(CMake_VERSION_MAJOR 3)
 set(CMake_VERSION_MINOR 7)
-set(CMake_VERSION_PATCH 20170118)
+set(CMake_VERSION_PATCH 20170119)
 #set(CMake_VERSION_RC 1)

---

Summary of changes:
 Source/CMakeVersion.cmake |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

Re: [CMake] Managing a local installation of cmake-built open source packages

[Elizabeth A. Fischer]

Ardi,

What you describe is pretty much what Spack does.  I would take a look at
it, see if it meets your needs.  Chances are, at least some of the packages
you need are already included in Spack:

https://github.com/llnl/spack

-- Elizabeth

On Wed, Jan 18, 2017 at 12:39 PM, ardi  wrote:

> Hi,
>
> I want to install (on UNIX-like systems) a collection of open source
> packages which use cmake as the build tool, but I need the
> installation to be performed in a local directory (inside my home
> directory), and I wish convenient updating to new versions of the
> packages.
>
> I didn't arrive to a convincing solution, so any advice will be welcome.
>
> Here are my thoughts:
>
> The trivial solution is of course to directly install to a non-root
> prefix when invoking cmake, but, however, this isn't well suited for
> updating a previous installation of the packages (building and
> installing a new version will only overwrite files that have the same
> name, but it will keep old files that no longer exist in the new
> version, cluttering the local installation directory with no longer
> needed and mismatched files).
>
> A possibility would be to keep a copy of install_manifest.txt whenever
> I install a package, and remembering to always run 'xargs rm <
> install_manifest.txt' before installing a different version of a
> previously installed package.
>
> But keeping the install_manifest.txt of each installed package (and
> using it before updating a package) looks like a too-manual task,
> candidate to some kind of automation.
>
> Another (perhaps wiser) possibility would be to use cpack for creating
> either a RPM or DEB, and then use the corresponding package manager to
> install the package. But this has problems too: most package managers
> assume a / root installation directory. Also, I use several OSs: OSX,
> Linux, and some BSDs, and I'm not sure that either the RPM nor the DEB
> pkg managers will work flawlessly across all the OSs I use.
>
> What would you recommend here?
>
> Thanks a lot!
> --
>
> 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
>
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Managing a local installation of cmake-built open source packages

[Domen Vrankar]

2017-01-18 22:37 GMT+01:00 ardi :

> If anybody has further suggestions, please don't hesitate to tell.
>

Alternative 1:
I usually go with the platform supported packages even if that means having
more than one package format... I prefer less custom dependencies to
one-package-to-rule-them-all logic specially since most of the time
programs already have to be recompiled on each platform. For me less custom
dependencies is worth far more than having only one package type to
maintain.

Since you're saying that you can already install the files through CMake
you've already won half the battle - the installation part is basis for all
CPack packages (you set 2-3 variables and you have minimal RPM or DEB
package(s) - even component packages if install commands have components).
I don't know about the rest of the packagers but CPackRPM and Deb are quite
similar in that regard so there is not too much of a learning curve. If you
don't maintain the packages and they don't use CPack it's easy to append
the rules at the end of the root CMakeLists.txt (I did that for C++ version
of apache qpid a while back and produced minimal component RPM packages for
AIX OS in under 5 minutes).

Regarding installation on a different location as I said I'm not too
familiar with the rest of the packagers but you can create a custom package
database for both RPM and Deb packages and then install them on a different
location (relocatable RPM or a bit hackish way with Deb packages - see
LONG_FILENAMES/VerifiResult.cmake CMake test for an example with deb
packages).

Alternative 2:
You were talking about install_manifest.txt file. CPack  Archive packagier
(particularly STGZ - self extracting tar gz - version) could easily be
extended to produce such file and check for it on next install (asking you
if you'd really like to delete the content or something similar).
 Contributing something like that to CPack would even remove the burden of
maintaining a patched cpack version yourself.
Drawbacks are that you loose files database that comes with rpm/deb (nobody
will warn you if a file has been changed, was present in two packages etc.)
and also the currently-not-supported-by-cpack part (but since it's fairly
easy to implement we could probably get it into next CMake release).

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

[CMake] Managing a local installation of cmake-built open source packages

[ardi]

Thanks a lot, Guillaume, I didn't know about these tools, it's the first
time I hear of hunter and conan.

Thinking twice, I think that what I need is something similar to BSD ports,
or MacPorts, but with the difference that I don't want to patch anything,
just install and build the source as is, and in a multi build environment.

It seems that both hunter and conan seem to be similar to BSD ports in
nature, so I'll look at them.

If anybody has further suggestions, please don't hesitate to tell.

Thanks!


On Wed, Jan 18, 2017 at 9:11 PM, Guillaume Dumont <
dumont.guilla...@gmail.com > wrote:
> You can have a look at:
>
> Hunter: https://github.com/ruslo/hunter
> Conan: https://conan.io/
>
> HTH
>
> Guillaume
>
>
> On Wed, Jan 18, 2017 at 1:47 PM, Konstantin Podsvirov
> > wrote:
>>
>> 18.01.2017, 21:32, "ardi" >:
>>
>> On Wed, Jan 18, 2017 at 7:19 PM, Konstantin Podsvirov
>> > wrote:
>>
>>  Hello Ardi!
>>
>>
>> [...]
>>
>>
>>
>>  Sounds like, you need cross-platform (several desktops) package manager
>>  compatible with cmake.
>>
>>  If all desktops with GUI, what about using CPack IFW generator?
>>
>>  https://cmake.org/cmake/help/latest/module/CPackIFW.html
>>
>>
>> Thanks for the idea, Konstantin. Yes, all the OSs I use have a GUI,
>> although I don't use Qt. If the best solution is IFW, I'd use Qt only
>> for this. BTW, I'm new to IFW, and if I'm reading it correctly, cpack
>> generates an installer, which I guess is an executable... but... can
>> the installer also be used for uninstalling? Will an installer of a
>> new version of a package uninstall an older version if it exists?
>>
>> CPack IFW generator help you to create installer (yes, it's executable
>> based on Qt,
>> but static linked) thats you need run on target platform (you don't have
>> preinstalled Qt).
>>
>> CPack IFW generator can also help you to create packages repository to
use
>> from installers
>> (local or from network).
>>
>> Installer will remove old package before update him to new version.
>>
>> --
>> Regards,
>> Konstantin Podsvirov
>>
>>
>> --
>>
>> 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
>
>
>
>
> --
> Guillaume Dumont
> =
> dumont.guilla...@gmail.com 
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [Discussion] Down with discrimination CPack!

[Alexander Neundorf]

On 2017 M01 18, Wed 22:20:14 CET Konstantin Podsvirov wrote:
> What about add to CMake language new packaging problematic scopes:
> 
> - COMPONENT;
> - COMPONENT_GROUP;
> - PACKAGE;
> - INSTALLER;
> - REPOSITORY?

that's a quite terse proposal...

Alex


-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Requesting Advice: Installing object files

[Ben Boeckel]

On Wed, Jan 18, 2017 at 11:47:42 -0800, Chris Bieneman wrote:
> On Jan 18, 2017, at 5:58 AM, Ben Boeckel  wrote:
> > Plus our plan for installing OBJECT libraries was to install them as
> > INTERFACE libraries, leaving the objects themselves behind. The idea is
> > to allow object libraries into target_link_libraries() for usage
> > requirements and to support exporting them as part of the build system
> > (an explicit $ would still be required to use their
> > objects due to issues with transitive linking causing duplicate symbols
> > if target_sources were used).
> 
> Ah... that wouldn't work for us because we actually need the objects
> to be installed in the final product.

So I talked with Rob about this a bit and the INTERFACE bit is actually
the *exporting* of the target. Installing the target can install the
objects. I think the way this could work is that if it is installed, the
objects go and if they are exported, they are exported as an INTERFACE
library which supports a $ genex (and if the target is
not installed, it wouldn't work).

There will need to be some thought on it since there isn't a "just
export the target" mechanism yet. Off the top of my head, I'd like to
see install() have a INSTALL_OBJECTS keyword to cause OBJECT libraries
to put their objects anywhere (since I suspect it will be an uncommon
use case versus the need for a way to export the targets to an install
tree).

--Ben
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Managing a local installation of cmake-built open source packages

[Guillaume Dumont]

You can have a look at:

Hunter: https://github.com/ruslo/hunter
Conan: https://conan.io/

HTH

Guillaume


On Wed, Jan 18, 2017 at 1:47 PM, Konstantin Podsvirov <
konstan...@podsvirov.pro> wrote:

> 18.01.2017, 21:32, "ardi" :
>
> On Wed, Jan 18, 2017 at 7:19 PM, Konstantin Podsvirov
>  wrote:
>
>  Hello Ardi!
>
>
> [...]
>
>
>  Sounds like, you need cross-platform (several desktops) package manager
>  compatible with cmake.
>
>  If all desktops with GUI, what about using CPack IFW generator?
>
>  https://cmake.org/cmake/help/latest/module/CPackIFW.html
>
>
> Thanks for the idea, Konstantin. Yes, all the OSs I use have a GUI,
> although I don't use Qt. If the best solution is IFW, I'd use Qt only
> for this. BTW, I'm new to IFW, and if I'm reading it correctly, cpack
> generates an installer, which I guess is an executable... but... can
> the installer also be used for uninstalling? Will an installer of a
> new version of a package uninstall an older version if it exists?
>
> CPack IFW generator help you to create installer (yes, it's executable
> based on Qt,
> but static linked) thats you need run on target platform (you don't have
> preinstalled Qt).
>
> CPack IFW generator can also help you to create packages repository to use
> from installers
> (local or from network).
>
> Installer will remove old package before update him to new version.
>
> --
> Regards,
> Konstantin Podsvirov
>
>
> --
>
> 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
>



-- 
Guillaume Dumont
=
dumont.guilla...@gmail.com
-- 

Powered by www.kitware.com

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

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

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

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

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

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

[Jakob van Bethlehem]

Hej,

CMake experts may correct me if I'm wrong, but this is actually indeed not
supported (yet). Even though an object-library looks like any ordinary
library, in fact it is just a kind of 'shortcut' for a bunch of object
files - it is *not* a proper cmake TARGET. Some additional explanation can
be found here:
https://cmake.org/cmake/help/latest/manual/cmake-buildsystem.7.html#object-libraries

So, then the question obviously becomes how to achieve the desired result.
If the creation of out.map only depends on that one source file, I'd expect
you get the wanted result if instead of writing 'DEPENDS liblface', you
write 'DEPENDS iface.cpp' - I'm not totally sure though.

Sincerely,
Jakob


On Sun, Jan 15, 2017 at 12:35 AM, Paul Smith  wrote:

> If I create an OBJECT library:
>
>   add_library(libIface OBJECT iface.cpp)
>
> Then I create a custom command that depends on this:
>
>   add_custom_command(OUTPUT out.map
>   COMMAND touch out.map
>   DEPENDS libIface
>   VERBATIM)
>
> It doesn't work: the dependency is missing so when I edit the iface.cpp
> file the custom command is not run.  I'm using the Makefile generator,
> on Linux, and if I look at the generated makefile it's obvious that
> there's nothing there representing the OBJECT library:
>
>   out.map:
> @$(CMAKE_COMMAND) -E ... "Generating out.map"
> touch out.map
>
> The documentation for add_custom_command() clearly says that DEPENDS can
> specify "any target (created by the ... add_library() command)".
>
> Is there something missing from the docs that should say it doesn't work
> with OBJECT libraries, or is this a bug in cmake?
>
>
> Repro:
>
> 
> $ cat CMakeLists.txt
> cmake_minimum_required(VERSION 3.5)
> project(MapTest)
>
> add_library(libIface OBJECT iface.cpp)
>
> add_custom_command(OUTPUT out.map
> COMMAND touch out.map
> DEPENDS libIface
> VERBATIM)
>
> add_custom_target(libIfaceMap DEPENDS out.map)
>
> add_library(iface SHARED $ out.map)
>
> $ touch iface.cpp
>
> $ cmake .
>
> $ make
> Scanning dependencies of target libIface
> [ 33%] Building CXX object CMakeFiles/libIface.dir/iface.cpp.o
> [ 33%] Built target libIface
> [ 66%] Generating out.map
> Scanning dependencies of target iface
> [100%] Linking CXX shared library libiface.so
> [100%] Built target iface
>
> $ touch iface.cpp
>
> $ make
> Scanning dependencies of target libIface
> [ 33%] Building CXX object CMakeFiles/libIface.dir/iface.cpp.o
> [ 33%] Built target libIface
> [ 66%] Linking CXX shared library libiface.so
> [100%] Built target iface
> 
>
> Note that in the last step the "out.map" file was not recreated even
> though iface.cpp was modified.
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at http://www.kitware.com/
> opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Requesting Advice: Installing object files

[Chris Bieneman]

> On Jan 18, 2017, at 5:58 AM, Ben Boeckel  wrote:
> 
> On Wed, Jan 18, 2017 at 10:14:26 +0100, Nils Gladitz wrote:
>> On 17.01.2017 23:25, Chris Bieneman wrote:
>>> Hello CMake-developers!
>>> 
>>> In one of the LLVM sub-projects we have a problem where we need to 
>>> install object files, which doesn't seem like a particularly easy 
>>> task. I'm curious if anyone has any advice on how to approach this 
>>> problem.
>>> 
>>> The patch is currently being reviewed here:
>>> https://reviews.llvm.org/D28791
>>> 
>>> Since the object files have fairly simple compile commands our current 
>>> approach is to compile the files in custom commands, then use 
>>> install(FILES...). This is workable, but I'm wondering if there is a 
>>> better way. They do need to be object files, static archives would not 
>>> work because these specially named files are handled by linkers and 
>>> other tools that we don't control.
>> 
>> Also more of a workaround but perhaps you could create static libraries 
>> but extract them with e.g. CMAKE_AR (toolchain specific) during either 
>> installation e.g. install(CODE|SCRIPT) or as a POST_BUILD custom command.

We could consider this, but I'm not sure that this is really any simpler than 
what we're doing.

> 
> This issue might be the best way to go:
> 
>https://gitlab.kitware.com/cmake/cmake/issues/15226 
> 

If this allowed TARGET_OBJECTS to be used in the install(FILES ...) command, 
then we could create an object library and a custom install rule for the 
objects, which would be a lot cleaner.

> 
>> An OBJECT library might be better suited in theory but I don't think it 
>> currently allows installation and the location of the object files is 
>> generator specific (and afair not always known to cmake).
>> By doing a manual extraction of the archive you'd be in control over 
>> where the objects go.
> 
> Plus our plan for installing OBJECT libraries was to install them as
> INTERFACE libraries, leaving the objects themselves behind. The idea is
> to allow object libraries into target_link_libraries() for usage
> requirements and to support exporting them as part of the build system
> (an explicit $ would still be required to use their
> objects due to issues with transitive linking causing duplicate symbols
> if target_sources were used).

Ah... that wouldn't work for us because we actually need the objects to be 
installed in the final product.

Thanks!
-Chris

> 
> --Ben

-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] [Discussion] Down with discrimination CPack!

[Konstantin Podsvirov]

What about add to CMake language new packaging problematic scopes: - COMPONENT;- COMPONENT_GROUP;- PACKAGE;- INSTALLER;- REPOSITORY? --Regards,Konstantin Podsvirov 
-- 

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] Managing a local installation of cmake-built open source packages

[Konstantin Podsvirov]

18.01.2017, 21:32, "ardi" :On Wed, Jan 18, 2017 at 7:19 PM, Konstantin Podsvirov wrote: Hello Ardi! [...]  Sounds like, you need cross-platform (several desktops) package manager compatible with cmake. If all desktops with GUI, what about using CPack IFW generator? https://cmake.org/cmake/help/latest/module/CPackIFW.htmlThanks for the idea, Konstantin. Yes, all the OSs I use have a GUI,although I don't use Qt. If the best solution is IFW, I'd use Qt onlyfor this. BTW, I'm new to IFW, and if I'm reading it correctly, cpackgenerates an installer, which I guess is an executable... but... canthe installer also be used for uninstalling? Will an installer of anew version of a package uninstall an older version if it exists?CPack IFW generator help you to create installer (yes, it's executable based on Qt,but static linked) thats you need run on target platform (you don't have preinstalled Qt). CPack IFW generator can also help you to create packages repository to use from installers(local or from network). Installer will remove old package before update him to new version. --Regards,Konstantin Podsvirov -- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Managing a local installation of cmake-built open source packages

[ardi]

On Wed, Jan 18, 2017 at 7:19 PM, Konstantin Podsvirov
 wrote:
> Hello Ardi!
>
[...]
>
> Sounds like, you need cross-platform (several desktops) package manager
> compatible with cmake.
>
> If all desktops with GUI, what about using CPack IFW generator?
>
> https://cmake.org/cmake/help/latest/module/CPackIFW.html

Thanks for the idea, Konstantin. Yes, all the OSs I use have a GUI,
although I don't use Qt. If the best solution is IFW, I'd use Qt only
for this. BTW, I'm new to IFW, and if I'm reading it correctly, cpack
generates an installer, which I guess is an executable... but... can
the installer also be used for uninstalling? Will an installer of a
new version of a package uninstall an older version if it exists?
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Managing a local installation of cmake-built open source packages

[Konstantin Podsvirov]

Hello Ardi! 18.01.2017, 20:39, "ardi" :Hi,I want to install (on UNIX-like systems) a collection of open sourcepackages which use cmake as the build tool, but I need theinstallation to be performed in a local directory (inside my homedirectory), and I wish convenient updating to new versions of thepackages.I didn't arrive to a convincing solution, so any advice will be welcome.Here are my thoughts:The trivial solution is of course to directly install to a non-rootprefix when invoking cmake, but, however, this isn't well suited forupdating a previous installation of the packages (building andinstalling a new version will only overwrite files that have the samename, but it will keep old files that no longer exist in the newversion, cluttering the local installation directory with no longerneeded and mismatched files).A possibility would be to keep a copy of install_manifest.txt wheneverI install a package, and remembering to always run 'xargs rm 

[CMake] Managing a local installation of cmake-built open source packages

[ardi]

Hi,

I want to install (on UNIX-like systems) a collection of open source
packages which use cmake as the build tool, but I need the
installation to be performed in a local directory (inside my home
directory), and I wish convenient updating to new versions of the
packages.

I didn't arrive to a convincing solution, so any advice will be welcome.

Here are my thoughts:

The trivial solution is of course to directly install to a non-root
prefix when invoking cmake, but, however, this isn't well suited for
updating a previous installation of the packages (building and
installing a new version will only overwrite files that have the same
name, but it will keep old files that no longer exist in the new
version, cluttering the local installation directory with no longer
needed and mismatched files).

A possibility would be to keep a copy of install_manifest.txt whenever
I install a package, and remembering to always run 'xargs rm <
install_manifest.txt' before installing a different version of a
previously installed package.

But keeping the install_manifest.txt of each installed package (and
using it before updating a package) looks like a too-manual task,
candidate to some kind of automation.

Another (perhaps wiser) possibility would be to use cpack for creating
either a RPM or DEB, and then use the corresponding package manager to
install the package. But this has problems too: most package managers
assume a / root installation directory. Also, I use several OSs: OSX,
Linux, and some BSDs, and I'm not sure that either the RPM nor the DEB
pkg managers will work flawlessly across all the OSs I use.

What would you recommend here?

Thanks a lot!
-- 

Powered by www.kitware.com

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

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

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

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

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

[Cmake-commits] CMake branch, next, updated. v3.7.2-2230-gcba760d

[Ben Boeckel]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, next has been updated
   via  cba760da8de27c311918f2d33ff7f27193f6e6af (commit)
   via  8c1cfb945a4fe63caa4f5d9fc33fbe2c3731a3ca (commit)
   via  fe8e00f6b91d7e8614af5a5ffb2ab68775b06e1c (commit)
  from  f38f5c7b2003bd0865d395e07f015d5d8c1580a7 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=cba760da8de27c311918f2d33ff7f27193f6e6af
commit cba760da8de27c311918f2d33ff7f27193f6e6af
Merge: f38f5c7 8c1cfb9
Author: Ben Boeckel 
AuthorDate: Wed Jan 18 12:30:50 2017 -0500
Commit: CMake Topic Stage 
CommitDate: Wed Jan 18 12:30:50 2017 -0500

Merge topic 'add-dl-to-lua-static-linking' into next

8c1cfb94 Add dl library to Lua static library linking
fe8e00f6 CMake Nightly Date Stamp


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8c1cfb945a4fe63caa4f5d9fc33fbe2c3731a3ca
commit 8c1cfb945a4fe63caa4f5d9fc33fbe2c3731a3ca
Author: Michael Krasnyk 
AuthorDate: Wed Jan 18 15:22:20 2017 +0100
Commit: Michael Krasnyk 
CommitDate: Wed Jan 18 18:01:50 2017 +0100

Add dl library to Lua static library linking

diff --git a/Modules/FindLua.cmake b/Modules/FindLua.cmake
index 5be0428..c777970 100644
--- a/Modules/FindLua.cmake
+++ b/Modules/FindLua.cmake
@@ -172,6 +172,13 @@ if (LUA_LIBRARY)
 if (UNIX AND NOT APPLE AND NOT BEOS)
 find_library(LUA_MATH_LIBRARY m)
 set(LUA_LIBRARIES "${LUA_LIBRARY};${LUA_MATH_LIBRARY}")
+
+# include dl library for statically-linked Lua library
+get_filename_component(LUA_LIB_EXT ${LUA_LIBRARY} EXT)
+if(LUA_LIB_EXT STREQUAL CMAKE_STATIC_LIBRARY_SUFFIX)
+  list(APPEND LUA_LIBRARIES ${CMAKE_DL_LIBS})
+endif()
+
 # For Windows and Mac, don't need to explicitly include the math library
 else ()
 set(LUA_LIBRARIES "${LUA_LIBRARY}")

---

Summary of changes:
 Modules/FindLua.cmake |7 +++
 Source/CMakeVersion.cmake |2 +-
 2 files changed, 8 insertions(+), 1 deletion(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

[Cmake-commits] CMake branch, next, updated. v3.7.2-2227-gf38f5c7

[Ben Boeckel]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, next has been updated
   via  f38f5c7b2003bd0865d395e07f015d5d8c1580a7 (commit)
   via  7f0a21a51eb483c523a2c8880ce4e0466251ec74 (commit)
  from  9d16616b45a62a9b398cff89d9801a7e9af264b0 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f38f5c7b2003bd0865d395e07f015d5d8c1580a7
commit f38f5c7b2003bd0865d395e07f015d5d8c1580a7
Merge: 9d16616 7f0a21a
Author: Ben Boeckel 
AuthorDate: Wed Jan 18 12:29:52 2017 -0500
Commit: CMake Topic Stage 
CommitDate: Wed Jan 18 12:29:52 2017 -0500

Merge topic 'case-insensitive-bindir-detection' into next

7f0a21a5 cmSystemTools: use the actual case for root detection


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7f0a21a51eb483c523a2c8880ce4e0466251ec74
commit 7f0a21a51eb483c523a2c8880ce4e0466251ec74
Author: Ben Boeckel 
AuthorDate: Wed Jan 18 10:06:23 2017 -0500
Commit: Ben Boeckel 
CommitDate: Wed Jan 18 10:08:40 2017 -0500

cmSystemTools: use the actual case for root detection

On Windows, calling a binary installed with the default `bin` binary
directory will fail to be detected when called as `BIN\cmake.exe` due to
the string compare. Get the actual case of the path before checking that
the path ends with `CMAKE_BIN_DIR`.

Fixes #16574.

diff --git a/Source/cmSystemTools.cxx b/Source/cmSystemTools.cxx
index 3d8fdf5..e693beb 100644
--- a/Source/cmSystemTools.cxx
+++ b/Source/cmSystemTools.cxx
@@ -1979,7 +1979,8 @@ void cmSystemTools::FindCMakeResources(const char* argv0)
   // Install tree has
   // - "/cmake"
   // - ""
-  if (cmHasSuffix(exe_dir, CMAKE_BIN_DIR)) {
+  const std::string actual_case = cmSystemTools::GetActualCaseForPath(exe_dir);
+  if (cmHasSuffix(actual_case, CMAKE_BIN_DIR)) {
 std::string const prefix =
   exe_dir.substr(0, exe_dir.size() - strlen(CMAKE_BIN_DIR));
 cmSystemToolsCMakeRoot = prefix + CMAKE_DATA_DIR;

---

Summary of changes:
 Source/cmSystemTools.cxx |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

[CMake] Multi-line strings with indentation ignored

[Robert Dailey]

At the moment, with CMake 3.0 and on, I can use this syntax for
multi-line strings:


option( ZIOSK_ENABLE_ZPAY_DIAGNOSTICS "\
Enable additional diagnostic logs for zPay related code. \
Should not be enabled for production due to the sensitivity \
and volume of logs that will be printed." )

The problem with this approach is that it's ugly; I can't indent the
code because the indentations are made to be a literal part of the
string itself. I prefer the C++ approach to multi-line strings because
it allows strings to be hard-wrapped AND indent them for style, all
without affecting the actual string data:

option( ZIOSK_ENABLE_ZPAY_DIAGNOSTICS
"Enable additional diagnostic logs for zPay related code. "
"Should not be enabled for production due to the sensitivity "
"and volume of logs that will be printed" )

This is much nicer, but CMake fails this code because it sees each
string as a separate parameter. Is there a mechanism I can use to
style my strings this way? If not, are there any plans to add better
multi-line string support?
-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] Multi-line strings with indentation ignored

[Robert Dailey]

At the moment, with CMake 3.0 and on, I can use this syntax for
multi-line strings:


option( ZIOSK_ENABLE_ZPAY_DIAGNOSTICS "\
Enable additional diagnostic logs for zPay related code. \
Should not be enabled for production due to the sensitivity \
and volume of logs that will be printed." )

The problem with this approach is that it's ugly; I can't indent the
code because the indentations are made to be a literal part of the
string itself. I prefer the C++ approach to multi-line strings because
it allows strings to be hard-wrapped AND indent them for style, all
without affecting the actual string data:

option( ZIOSK_ENABLE_ZPAY_DIAGNOSTICS
"Enable additional diagnostic logs for zPay related code. "
"Should not be enabled for production due to the sensitivity "
"and volume of logs that will be printed" )

This is much nicer, but CMake fails this code because it sees each
string as a separate parameter. Is there a mechanism I can use to
style my strings this way? If not, are there any plans to add better
multi-line string support?
-- 

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] pkg_check_modules does not respond to changes.

[Matthew Hanna (BLOOMBERG/ 731 LEX)]

There is an optimization in pkg_check_modules that skips processing
once a successful execution has occurred and simply leaves the cached
return variables as is.  As currently implemented, any changes to the
parameters of pkg_check_modules, excluding PREFIX, will be ignored
following a successful execution.  Workarounds include modifying the
PREFIX and all references to it, or starting over from an empty build
directory.  Adding a pkg-config dependency after the initial
configuration is a regular part of our development workflow and the
existing workarounds are cumbersome.

I would like to enhance the behavior of pkg_check_modules to store the
parameters for a given PREFIX so that changes to those parameters can
disable the optimization and re-evaluate pkg_check_modules.

Are there any concerns about or objections to adding this behavior?

If not, should this change in behavior be noted in the documentation?-- 

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] Requesting Advice: Installing object files

[Ben Boeckel]

On Wed, Jan 18, 2017 at 10:14:26 +0100, Nils Gladitz wrote:
> On 17.01.2017 23:25, Chris Bieneman wrote:
> > Hello CMake-developers!
> >
> > In one of the LLVM sub-projects we have a problem where we need to 
> > install object files, which doesn't seem like a particularly easy 
> > task. I'm curious if anyone has any advice on how to approach this 
> > problem.
> >
> > The patch is currently being reviewed here:
> > https://reviews.llvm.org/D28791
> >
> > Since the object files have fairly simple compile commands our current 
> > approach is to compile the files in custom commands, then use 
> > install(FILES...). This is workable, but I'm wondering if there is a 
> > better way. They do need to be object files, static archives would not 
> > work because these specially named files are handled by linkers and 
> > other tools that we don't control.
> 
> Also more of a workaround but perhaps you could create static libraries 
> but extract them with e.g. CMAKE_AR (toolchain specific) during either 
> installation e.g. install(CODE|SCRIPT) or as a POST_BUILD custom command.

This issue might be the best way to go:

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

> An OBJECT library might be better suited in theory but I don't think it 
> currently allows installation and the location of the object files is 
> generator specific (and afair not always known to cmake).
> By doing a manual extraction of the archive you'd be in control over 
> where the objects go.

Plus our plan for installing OBJECT libraries was to install them as
INTERFACE libraries, leaving the objects themselves behind. The idea is
to allow object libraries into target_link_libraries() for usage
requirements and to support exporting them as part of the build system
(an explicit $ would still be required to use their
objects due to issues with transitive linking causing duplicate symbols
if target_sources were used).

--Ben
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Requesting Advice: Installing object files

[Nils Gladitz]

On 17.01.2017 23:25, Chris Bieneman wrote:

Hello CMake-developers!

In one of the LLVM sub-projects we have a problem where we need to 
install object files, which doesn't seem like a particularly easy 
task. I'm curious if anyone has any advice on how to approach this 
problem.


The patch is currently being reviewed here:
https://reviews.llvm.org/D28791

Since the object files have fairly simple compile commands our current 
approach is to compile the files in custom commands, then use 
install(FILES...). This is workable, but I'm wondering if there is a 
better way. They do need to be object files, static archives would not 
work because these specially named files are handled by linkers and 
other tools that we don't control.


Also more of a workaround but perhaps you could create static libraries 
but extract them with e.g. CMAKE_AR (toolchain specific) during either 
installation e.g. install(CODE|SCRIPT) or as a POST_BUILD custom command.


An OBJECT library might be better suited in theory but I don't think it 
currently allows installation and the location of the object files is 
generator specific (and afair not always known to cmake).
By doing a manual extraction of the archive you'd be in control over 
where the objects go.


Nils
--

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