Re: [CMake] Dependency managment

[Attila Krasznahorkay]

Hi Gabriele,

What do you mean exactly by "we can compile libA but we cannot compile libB 
without installing libA because the latter needs it"? o.O Are you trying to 
find libA in libs/libB/CMakeLists.txt with find_package(...)?

"Normal" targets (libraries and executables) should be globally visible after 
you defined them. This is the default behaviour of CMake. So if you define libA 
correctly, you would just need to link libB against it (using 
target_link_libraries(...)) for the whole thing to work correctly. (libB 
waiting for libA to finish, and then using its headers and linking against its 
library file.)

There are literally countless number of examples out there in the wild for 
doing this. Here is one example for instance:

https://gitlab.com/atomki-nuclear-phys/cda

That project also very generously uses add_subdirectory(...). And targets in 
the subdirectories depend on each other in not completely trivial ways. (Mind 
you, as long as you set everything up correctly, it doesn't even matter in 
which order you include the subdirectories. It's fine to first include one that 
depends on a library whose definition is only included later on.)

Cheers,
 Attila

> On 12 Dec 2018, at 14:01, Ciccio Pasticcio  
> wrote:
> 
> Hi all, 
> we are trying to re-design the build system of an existing complex project 
> using cmake.
> We have a source tree such this (it is only an example to help explaining the 
> problem)
> 
> .
> └── libs
> ├── CMakeLists.txt  
> ├── libA
> │   ├── CMakeLists.txt
> │   ├── include
> │   │   └── libA.h
> │   └── source
> │   └── libA.cpp
> └── libB
> ├── CMakeLists.txt
> ├── include
> │   └── libB.h
> └── source
> └── libB.cpp
> 
> The tree contains libraries and executables and many of them have some 
> dependencies to be
> satisfied. We wrote a CMakeLists.txt file on top of the hyerarchy which 
> repetitively uses the
> add_directory directive to build every project under it. This solution seems 
> to work well 
> until a project needs another one to be built; in other words, we did not 
> find out how to deal 
> with dependencies. Looking at the tree above, we can compile libA but we 
> cannot compile libB without 
> installing libA because the latter needs it. What's the right and easy way to 
> make a target globally 
> available or at least available for projects on the same level?
> 
> Thanks, 
> Gabriele
> -- 
> 
> 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

-- 

Powered by www.kitware.com

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

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

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

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

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

[CMake] DEPFILE usage in add_custom_command(...)

[Attila Krasznahorkay]

Dear All,

I'm trying to use the DEPFILE argument of add_custom_command(...) to be able to 
tell Ninja exactly when it should re-run that custom command. But unfortunately 
I'm not able to get it to work as I'd like. :-(

I'm running a custom command that processes a header file through a custom 
executable. (It's a long story, see 
https://gitlab.kitware.com/cmake/cmake/issues/18695 and 
https://gitlab.kitware.com/cmake/cmake/issues/16830 for some more details.) I 
run that custom executable using a script file that I generate during the CMake 
configuration. In that script file I generate a dependency file using:

   set( cmd "${cmd}${CMAKE_CXX_COMPILER} -I\"$\"" )
   set( cmd "${cmd} -D$" )
   if( CMAKE_OSX_SYSROOT )
  set( cmd "${cmd} -isysroot ${CMAKE_OSX_SYSROOT}" )
   endif()
   set( cmd "${cmd} -MM -MT ${rootmap_name} -MF ${dictname}.d ${ARG_HEADER}\n" )

This then results in a file like:

/Users/krasznaa/ATLAS/sw/projects/volatile/externals/build_test/DictionaryPackage/CMakeFiles/DictionaryPackageDict.dsomap:
 \
  
/Users/krasznaa/ATLAS/sw/projects/volatile/externals/build_test/DictionaryPackage/CMakeFiles/DictionaryPackageDict.h
 \
  
/Users/krasznaa/ATLAS/sw/projects/volatile/externals/CMakeDictionaryTests/DictionaryPackage/DictionaryPackage/MyClass.h
 \
  
/Users/krasznaa/ATLAS/sw/projects/volatile/externals/CMakeDictionaryTests/DictionaryPackage/DictionaryPackage/HelperHeader.h
 \
  
/Users/krasznaa/ATLAS/sw/projects/volatile/externals/CMakeDictionaryTests/DictionaryPackage/DictionaryPackage/MyOtherClass.h
 \
  
/Users/krasznaa/ATLAS/sw/projects/volatile/externals/CMakeDictionaryTests/AthLinks/AthLinks/DataLink.h
 \
  
/Users/krasznaa/ATLAS/sw/projects/volatile/externals/CMakeDictionaryTests/AthLinks/AthLinks/ElementLink.h
 \
  
/Users/krasznaa/ATLAS/sw/projects/volatile/externals/CMakeDictionaryTests/AthLinks/AthLinks/ElementLinkVector.h
 \
  
/Users/krasznaa/ATLAS/sw/projects/volatile/externals/CMakeDictionaryTests/AthContainers/AthContainers/tools/AuxTypeVectorFactory.h

Which looks correct to me. The generated Ninja file refers to this dependency 
file with:

#
# Custom command for DictionaryPackage/CMakeFiles/DictionaryPackageDict.dsomap

build DictionaryPackage/CMakeFiles/DictionaryPackageDict.dsomap 
DictionaryPackage/CMakeFiles/DictionaryPackageDictReflexDict.cxx 
x86_64-mac1014-clang100-opt/lib/libDictionaryPackageDict_rdict.pcm: 
CUSTOM_COMMAND DictionaryPackage/CMakeFiles/DictionaryPackageDict.h 
/Users/krasznaa/ATLAS/sw/projects/volatile/externals/CMakeDictionaryTests/DictionaryPackage/DictionaryPackage/DictionaryPackageDict.h
 DictionaryPackage/CMakeFiles/selection.xml 
DictionaryPackage/CMakeFiles/DictionaryPackageDict.h 
/Users/krasznaa/ATLAS/sw/projects/volatile/externals/CMakeDictionaryTests/DictionaryPackage/DictionaryPackage/DictionaryPackageDict.h
  COMMAND = cd 
/Users/krasznaa/ATLAS/sw/projects/volatile/externals/build_test/DictionaryPackage/CMakeFiles
 && /Users/krasznaa/Software/CMake/3.11.4/bin/cmake -E make_directory 
/Users/krasznaa/ATLAS/sw/projects/volatile/externals/build_test/x86_64-mac1014-clang100-opt/lib
 && sh 
/Users/krasznaa/ATLAS/sw/projects/volatile/externals/build_test/DictionaryPackage/CMakeFiles/makeDictionaryPackageDictReflexDict.sh
  DESC = Generating DictionaryPackageDictReflexDict.cxx
  depfile = 
/Users/krasznaa/ATLAS/sw/projects/volatile/externals/build_test/DictionaryPackage/CMakeFiles/DictionaryPackageDictReflexDict.d
  restat = 1

Which again, looks correct to me. But... This setup results in Ninja *always* 
re-running this command on every re-build. Even when I didn't modify any of the 
files referenced in that dependency file. :-(

Does anyone have an idea what I'm doing wrong? Unfortunately I didn't manage to 
find examples of using DEPFILE that would've helped me further than this... Any 
help would be very much appreciated.

Cheers,
 Attila

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] why can target_include_directories() not be applied to custom targets?

[Attila Krasznahorkay]

Hi,

Just to say that setting INCLUDE_DIRECTORIES on a custom target is indeed a bit 
of an obscure thing, but we do use it. You can find the full reasoning in:

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

Because of that, I understood that CMake will provide this functionality in the 
future as well, so we can rely on this build setup.

Cheers,
  Attila

> On 8 Jul 2018, at 12:16, Petr Kmoch  wrote:
> 
> Hi Drew,
> 
> a custom target can do literally anything, it's just a buildsystem wrapper 
> for running arbitrary executables; or often not even that, and is just a 
> collection of custom commands. There is nothing CMake automatically does with 
> the properties [INTERFACE_]INCLUDE_DIRECTORIES set on a custom command.
> 
> Note that if you need the properties set for some reason (i.e. if your custom 
> command/target code uses them for something), you can still set them just 
> fine using set_property() or set_target_properties(). However, I expect this 
> to be a very rare thing to do, so I think it's OK 
> target_include_directories() actually errors out on custom targets. IMO it's 
> much more likely that a non-custom target was intended.
> 
> (Note that I am just an ordinary CMake user, so the above is in no way 
> "official.")
> 
> Petr
> 
> On 7 July 2018 at 21:27, Drew Parsons  wrote:
> Commit 510fdcb18801076e2041eaae2941375eecc93ec2 at
> https://gitlab.kitware.com/cmake/cmake/commit/510fdcb18801076e2041eaae2941375eecc93ec2
> prevents custom targets from using target_include_directories().
> 
> This makes no sense to me.  A custom target is still a target. It needs
> to be compiled, it uses -I flags.
> 
> Can you explain the ban on applying target_include_directories() to
> custom targets?
> 
> Drew
> 
> -- 
> 
> 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
> 
> -- 
> 
> 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

-- 

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] Incremental builds with ExternalProject_Add

[Attila Krasznahorkay]

Dear All,

I ran into an issue with incremental builds that use ExternalProject_Add(...), 
which I'm very surprised isn't a more widely advertised issue. So I thought I'd 
ask here if people are aware of this behaviour...

For our software projects we build a good number of externals using separate 
"externals project".

https://gitlab.cern.ch/atlas/atlasexternals

Most of these externals we build by downloading tar files of their sources from 
various locations, and building those. Like for instance:

https://gitlab.cern.ch/atlas/atlasexternals/blob/master/External/ROOT/CMakeLists.txt

(Just to demonstrate how not trivial some of these builds already are...)

With one of the latest updates of this repository I started seeing some very 
unnerving compilation errors in our CI system, which lead me to realise that 
we've been using ExternalProject_Add(...) in a way so far that's fundamentally 
not CI compatible.

Let's take an example where I have two versions of an external. Let's download 
these versions in files external-1.0.0.tar.gz, and external-1.0.1.tar.gz. And 
let's assume that version 1.0.0 was created in January, while 1.0.1 in February 
of some year.

Now, if we just create a very simple ExternalProject_Add(...) configuration, 
that will just not be incremental build compatible in this setup. Since let's 
just walk through the build steps.
  - Let's say that it's March by now.
  - We first build version 1.0.0 of the external. When ExternalProject_Add(...) 
unpacks external-1.0.0.tar.gz, the source directory of this project will have 
modification dates from January. The built files on the other hand will have 
modification dates from March. (The current date.)
  - Now we update our build to use version 1.0.1 of the external. When 
ExternalProject_Add(...) unpacks external-1.0.1.tar.gz, the source files get 
updated to have modification dates from February. But remember, the build 
results have a modification date from March. So any reasonable build system 
that external-1.0.1.tar.gz may use, will not do anything. It will assume that 
the files in the build directory are already up to date.

Of course the issue is even worse when we try to downgrade the version of the 
external in an update of our own repository.

So my question is: Are people not running into this issue all the time? For now 
I'm thinking of solving this problem like:

https://gitlab.cern.ch/akraszna/IncrementalBuildTest/blob/master/CMakeLists.txt

Which is a quite drastic approach, but I don't know of a better one. And I 
wonder if ExternalProject_Add(...) should just behave like this out of the box 
by default. That whenever it downloads/unpacks a different version of an 
external than it built before, it should always purge the previous build 
completely.

What does everybody think about this? Am I missing something? Have I been using 
ExternalProject_Add(...) wrong all along?

Cheers,
   Attila
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] AUTOMOC with files on different folders

[Attila Krasznahorkay]

Hi Tiago,

Indeed, that page is quite a bit misleading. And it seems to be "liked" by 
Google a lot, as most people come across it. (I also found it myself when 
looking for CMake documentation early on.)

In general, listing all source files belonging to a library/executable, even 
the ones that are not compiled, is a good habit. As it makes the generated VS 
and Xcode projects much nicer to use.

I didn't look at the internals of the Qt CMake code. I just realised this 
behaviour while trying to make our own code work. (It's an intuitive behaviour, 
so it wasn't too hard to figure out.) I guess the code has some fallback to 
search for headers in the same place as their corresponding source file. Which 
can make the project still work without declaring the header files, as long as 
they are in the same directory with the source files. I imagine that doing 
something more complicated to look for the headers would not be so easy. (I 
can't even think of a reliable way of doing it myself. You can't just rely on 
the include paths of your component, as that would introduce a lot of possible 
problems.)

All in all, I just accepted this behaviour as-is.

Cheers,
   Attila

> On 12 May 2016, at 05:20, Hendrik Sattler  wrote:
> 
> 
> 
> Am 12. Mai 2016 00:00:12 MESZ, schrieb Tiago Macarios 
> :
>> Hi Attila,
>> 
>> Thank you for your help. You are right, if I apply the following
>> modifications it works indeed:
>> 
>> set( proj_HEADER
>>   include/a.h
>> )
>> 
>> add_library(proj SHARED ${proj_SOURCE} ${proj_HEADER})
>> 
>> But now I got a second question. Why is adding the header files
>> necessary?
>> (Sorry the possibly naive question)
>> 
>> I thought that adding the header files to the target was an
>> anti-pattern (
>> http://voices.canonical.com/jussi.pakkanen/2013/03/26/a-list-of-common-cmake-antipatterns/
>> ). Is it related to moc generating header files during the build? If so
>> why
>> is it not a problem when everything is on the same folder?
> 
> That same page has a Errata section at the end. 
> 
> -- 
> Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
> -- 
> 
> 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] AUTOMOC with files on different folders

[Attila Krasznahorkay]

Hi Tiago,

This is one of those cases when you have to declare the header files to 
add_library(...) as well. In that case AUTOMOC should work fine. At least it 
does for us, in a very similar setup.

http://acode-browser.usatlas.bnl.gov/lxr/source/atlas/graphics/VP1/VP1Gui/CMakeLists.txt

Cheers,
Attila

> On 11 May 2016, at 07:14, Tiago Macarios  wrote:
> 
> Hi,
> 
> I am having trouble using AUTOMOC with a project where header files and 
> source files are in different sub-directories. I wrote a detailed stack 
> overflow question here:
> http://stackoverflow.com/questions/37151163/cmake-automoc-with-files-on-different-folders
> and would really appreciate if someone could give me a couple of ideas to try 
> out.
> 
> Thanks,
> Tiago
> -- 
> 
> 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] Cannot include third-party Framework headers directories as system directories in XCode for avoiding their warning

[Attila Krasznahorkay]

Hi,

I'm a bit surprised by this. I had to explicitly tell CMake not to treat 
includes coming from imported targets as system includes. Using this variable:

https://cmake.org/cmake/help/v3.0/variable/CMAKE_NO_SYSTEM_FROM_IMPORTED.html
https://cmake.org/cmake/help/v3.0/prop_tgt/NO_SYSTEM_FROM_IMPORTED.html

So I think this is in general a MacOS specific issue. I remember reading about 
such issues a while ago. That CMake would not recognise that MacOS X's clang 
would accept the -isystem argument out of the box.

Cheers,
  Attila

> On 10 May 2016, at 18:16, tetractius  wrote:
> 
> Hi list,
> 
> I have an issue caused by a warning in the qt5 brew version in osx when using 
> Xcode generator
> 
> I can safely find the qt framework in the brew cellar:
> 
> set(CMAKE_PREFIX_PATH /usr/local/opt/qt5)
> find_package(Qt5Widgets REQUIRED)
> 
> and with this I can easily add this framework to my project by using
> 
> target_link_libraries(myApp Qt5::Widgets)
> 
> and this, as per documentation will cause to add all the -I directories> when compiling the .o files for this target.
> 
> The problem is that QT has some warning in their headers at the version 5.6 
> and 5.5.2_1 (that is all the qt5 the versions available in brew)
> and the -I it is not a system include parameter.
> 
> 
> So assuming that I cannot avoid to use the brew version and I cannot fix the 
> problems in the qt5 headers,
> 
> How can I tell to cmake that these framework include directories are system 
> include directories and thus they need to be included with -isystem in the 
> xcode project?
> 
> I tryed to manually pass the flag to the compiler but the 
> target_link_libraries function, when used with the framework, it will always 
> put their include directories in front of mine without the isystem flag.
> 
> 
> 
> -- 
> 
> 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] Running cpack without source folder

[Attila Krasznahorkay]

Hi,

If you run the cpack executable directly, it should not reconfigure/rebuild 
your project. As far as I know...

How do you run it now? "make package"? That will reconfigure/rebuild the 
project not really because of CPack, but because of how the Makefiles are set 
up.

Cheers,
Attila

> On 10 May 2016, at 09:43, Miklos Espak  wrote:
> 
> Hi,
> 
> given a complete build folder with all external projects, is it possible to 
> run cpack without touching the sources?
> 
> As I see, it now starts with configuring and building the project. (Skipping 
> what is up-to-date, usually everything.) This can cause a problem if you 
> switched branch after the built has finished and before running cpack.
> 
> Does cpack actually need anything from the sources? If not, is it possible to 
> tell cpack not to try to reconfig/rebuild the project?
> 
> Cheers,
> Miklos
> 
> -- 
> 
> 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] Difference between PRIVATE and PUBLIC with target_link_libraries

[Attila Krasznahorkay]

Hi Patrick,

I *think* that these public/private rules behave a bit differently for static 
libraries than they do for shared ones.

But I have to admit, that based on this code I also would've guessed that 
-I/tmp would not show up in the build of exe1...

I did manage to use public and private dependencies as expected in my own 
configurations, so I'm not exactly sure what's going wrong in your case. Which 
version of CMake did you use for the test?

Cheers,
  Attila

> On 10 May 2016, at 07:59, Patrick Boettcher  
> wrote:
> 
> Hi list,
> 
> What is the differences between PRIVATE and PUBLIC when used with
> target_link_libraries?
> 
> I read the help and understood that it works like in C++: PRIVATE will
> make everything which was PUBLIC before also PRIVATE if inherited
> privately.
> 
> An example:
> 
>  add_library(lib1 INTERFACE)
>  target_include_directories(lib1 INTERFACE /tmp)
> 
>  add_library(lib2 src2.c)
>  target_include_directories(lib2 PUBLIC /bin)
>  target_link_libraries(lib2 PRIVATE lib1) # PRIVATE here
> 
>  add_library(lib3 src3.c)
>  target_include_directories(lib3 PUBLIC /bin)
>  target_link_libraries(lib3 PUBLIC lib1) # PUBLIC here
> 
>  add_executable(exe1 exe.c)
>  target_link_libraries(exe1 lib2)
> 
>  add_executable(exe2 exe.c)
>  target_link_libraries(exe2 lib3)
> 
> 
> When building exe2 both include-dirs (from lib1 and lib3) are present:
> 
>  [..] -I/bin -I/tmp  [..]
> 
> as they are for exe1 - however I would have expected to not see /tmp
> because lib3 and lib1 are linked privately.
> 
> Where is my mistake?
> 
> Thanks,
> --
> Patrick.
> 
> -- 
> 
> 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

[CMake] Override CMAKE_SHARED_LINKER_FLAGS for one particular library

[Attila Krasznahorkay]

Dear All,

I have a similar issue as Matt Keeler. In our project we have some global 
linker flags that we set for all targets using the CMAKE_EXE_LINKER_FLAGS, 
CMAKE_SHARED_LINKER_FLAGS and CMAKE_MODULE_LINKER_FLAGS cache variables.

Now it turns out that for some libraries in the project I need to modify these 
flags. I can't modify the flags on the directory level, I need to modify them 
at the target level.

I tried just setting extra flags in LINK_FLAGS for my specific targets. But the 
problem is that the placement of the flags set in this target specific property 
is not "well defined" wrt. the global properties.

In this particular case we use "-Wl,--as-needed" globally for all of our 
targets. But for some particular libraries I'd like to turn this off. When I 
add "-Wl,--no-as-needed" to the LINK_FLAGS property of this library, it is put 
before the other flag in my final build configuration. And as such, it has no 
effect.

I tried modifying CMAKE_SHARED_LINKER_FLAGS before the add_library call for 
this library, and then restoring it to its original value afterwards. (Since as 
I said, I can't modify the flag for the entire directory.) But this didn't work 
as expected. Since by the generation stage CMake doesn't remember that the 
variable was set differently in the different lines of the directory's 
CMakeLists.txt file.

So, any ideas? I'd really hate to give up on using these global variables, and 
starting to set the flags one by one for all of our targets. Since it's a lot 
less work to just remove the flag for the targets that don't need it.

Cheers,
Attila
-- 

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] LINK_FLAGS directory property

[Attila Krasznahorkay]

Hi Matt,

Have you tried using the

CMAKE_EXE_LINKER_FLAGS
CMAKE_SHARED_LINKER_FLAGS
CMAKE_MODULE_LINKER_FLAGS

cache variables? These actually set these flags globally, and not just for one 
directory, but on the directory level they are easy to override. You can just 
do something like this in a subdirectory:

string( REPLACE "-Wl,--as-needed" "" CMAKE_SHARED_LINKER_FLAGS 
"${CMAKE_SHARED_LINKER_FLAGS}" )

Cheers,
Attila

> On 27 Apr 2016, at 17:57, Matthew Keeler  wrote:
> 
> Is there an equivalent directory property for the target level LINK_FLAGS 
> property. I can’t see anything according to the documentation but was hoping 
> there was an oversight and something actually existed.
> 
> What I am trying to do is pass extra flags to the linker for every target in 
> my project and I didn’t want to have to set it per target. I tried using the 
> link_libraries command but the flags I am adding are msvc specific and start 
> with ‘/‘ and cmake seems to be turning these into ‘\’ when its passed to the 
> linker. Then the linker thinks its trying to link in another file and 
> everything blows up.
> 
> Also a secondary question is what does the INTERPROCEDURAL_OPTIMIZATIONS 
> property at the directory level do. I assume on Windows it passes /GL to the 
> compiler but will this also add /LCTG to the linker flags and prevent 
> incremental linking. If I turn this property on will it also do it for debug 
> configurations or just optimized configurations?
> 
> -- 
> Matt Keeler
> 
> -- 
> 
> 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] Documenting CMakeLists.txt and custom or local .cmake files

[Attila Krasznahorkay]

Hi Philip,

Unfortunately I can't give any insight on this. I just wanted to express my own 
interest in this question. As we'd also very much need a convenient way to 
document our CMake code. (Currently it's done on a Wiki page, which is out of 
date within 5 minutes of it being updated...)

Cheers,
 Attila

> On 07 Apr 2016, at 04:51, Philip Miller  wrote:
> 
> Two days ago I posted this question on StackOverflow, 
> http://stackoverflow.com/q/36415261/3154588. I have not gotten an answer 
> there, so I thought I would ask on this list. 
> 
> What are good ways to document my project ``CMakeLists.txt`` files and local 
> project ``.cmake`` files? There is a two year old question/answer 
> http://stackoverflow.com/q/21628833/3154588 that I am essentially asking here 
> again. The answer contains the statement 
> 
>> Currently, CMake 3.0 is under development which will get a new documentation 
>> system based on Sphinx and reStructuredText. I guess that this will bring 
>> new ways to document your modules.
> 
> I have looked at the [cmake developer 
> documentation](https://cmake.org/cmake/help/v3.5/manual/cmake-developer.7.html?highlight=sphinx#id2),
>  but this *new documentation system* seems geared towards the documentation 
> of cmake itself. I do not see how I can use this to document my user-defined 
> project ``CMakeLists.txt`` files or local ``.cmake`` files. 
> 
> I am hoping that since the cmake project internally has various sphinx 
> directives and roles that there is was some way as a user I could take 
> advantage of this internal usage of sphinx. I would like to be able to have 
> some *markup* in my ``CMakeLists.txt`` files and local ``.cmake`` files 
> without having to reinvent the wheel. There are related efforts in other 
> projects. For example the ROS catkin project seems to offer the most complete 
> approach that I have seen, but that is fairly heavyweight not easy to use for 
> non-ROS projects. (As an example, look at their [extracted cmake api 
> page](http://docs.ros.org/api/catkin/html/dev_guide/generated_cmake_api.html).)
>  The simplest, is the 
> [sphinx-contrib](https://bitbucket.org/birkenfeld/sphinx-contrib/) 
> cmakedomain, but that relies on a separate rst source doc rather than an 
> *autodoc* approach with markup comments. 
> 
> I appreciate any help.
> Sincerely,
> Phil
> -- 
> 
> 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

[CMake] Check the existence of a header / ability to compile source file

[Attila Krasznahorkay]

Dear All,

I'm stumped on the following, seemingly simple issue.

I need to figure out in my configuration whether a given header file will be 
available when I'll try to build my library, or not. So that I could set a 
particular definition for the compiler according to whether the file is 
available or not.

The complication is that I use generator expressions very heavily in setting up 
the compilation flags of the library in question. So at configuration time I 
don't even know yet all the include directories that I should be looking in to 
find that header. That only becomes known after the generation step.

But as far as I can tell, check_include_files(...) can only run during the 
configuration step. So relying on generator expressions in setting up its 
include directories is not an option.

Is there any other possibility of making such a check, during the generation 
step? Or is there some other mechanism that I could use to do this check during 
the build itself? (After all, it could be a solution to generate a 
configuration header with this information during the build itself...)

Cheers,
  Attila
-- 

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] CPackRPM not dealing correctly with symlinks

[Attila Krasznahorkay]

Hi Domen,

I just tried, it seems to do the trick. An example source setup that was 
breaking the RPM building before, is now functioning seemingly correctly. The 
produced RPM gets the symlink, pointing at the location outside of the package.

I would actually prefer if the code printed a warning in this case. (Requesting 
a relocatable package, yet pointing at a fixed location outside of the 
package.) As in our case it was definitely a mistake to include soft links like 
this in our build. But if that's hard to add to the code, then so be it.

Cheers,
 Attila

> On 28 Mar 2016, at 18:38, Domen Vrankar <domen.vran...@gmail.com> wrote:
> 
> Attached is CPackRPM.cmake that fixes cases where symlink points to
> locations outside packaging directory.
> 
> Please confirm that it fixes your problem. Patched CPackRPM.cmake is
> from master branch so please replace the file in your 3.5.0 version of
> CMake.
> 
> Thanks,
> Domen
> 
> 2016-03-24 9:48 GMT+01:00 Attila Krasznahorkay 
> <attila.krasznahor...@gmail.com>:
>> Hi Domen,
>> 
>> Unfortunately I can't seem to create an easy-to-package example for the 
>> issue. Since it seems that the file given to the install(...) command has to 
>> be in a "very different place" than the source or binary directories for the 
>> issue to come up. (My guess is that if the file shares some of its path with 
>> the build directory, CPackRPM uses a different method for dealing with it 
>> than if the two paths don't share any prefix.)
>> 
>> In our case some files are picked up from a network drive, while the build 
>> happens (naturally) on a local drive. I can reproduce the issue with a 
>> CMakeLists.txt file like:
>> 
>> cmake_minimum_required( VERSION 2.8 )
>> project( CPackRPMLinkProblem )
>> 
>> install( FILES /afs/cern.ch/.../some_link.txt DESTINATION . )
>> 
>> set( CPACK_PACKAGE_RELOCATABLE TRUE )
>> include( CPack )
>> 
>> As long as the build directory's path name ends up being longer than the 
>> path name of the file specified in the install(...) command, the RPM 
>> building fails. As it does for instance here:
>> 
>> http://atlas-computing.web.cern.ch/atlas-computing/links/distDirectory/nightlies/experimentalWebArea/nicos_web_areaCMAKE64BS6G49AnlOpt/NICOS_Log_rel_4/nicos_rpm_build.html
>> 
>> Cheers,
>>   Attila
>> 
>>> On 23 Mar 2016, at 15:57, Domen Vrankar <domen.vran...@gmail.com> wrote:
>>> 
>>> As a workaround you could set files that you would like to be excluded
>>> from symlink relocation with CPACK_RPM_USER_FILELIST or
>>> CPACK_RPM__USER_FILELIST.
>>> 
>>> I'll have a look at how this could be solved for later versions of CPack.
>>> Do I understand correctly that those errors occur when a symlink is
>>> pointing to another simlink outside your project?
>>> Could you please provide a minimal example of all your cases?
>>> 
>>> Thanks,
>>> Domen
>>> 
>>> 
>>> 2016-03-23 14:13 GMT+01:00 Attila Krasznahorkay
>>> <attila.krasznahor...@gmail.com>:
>>>> Hi Brad,
>>>> 
>>>> I did. Then I get:
>>>> 
>>>> CMake Error at 
>>>> /afs/cern.ch/work/k/krasznaa/public/cmake/3.5.0/share/cmake-3.5/Modules/CPackRPM.cmake:981
>>>>  (string):
>>>> string begin index: 164 is out of range 0 - 156
>>>> Call Stack (most recent call first):
>>>> /afs/cern.ch/work/k/krasznaa/public/cmake/3.5.0/share/cmake-3.5/Modules/CPackRPM.cmake:1625
>>>>  (cpack_rpm_prepare_install_files)
>>>> /afs/cern.ch/work/k/krasznaa/public/cmake/3.5.0/share/cmake-3.5/Modules/CPackRPM.cmake:1787
>>>>  (cpack_rpm_generate_package)
>>>> 
>>>> You can find the full output here:
>>>> 
>>>> http://atlas-computing.web.cern.ch/atlas-computing/links/distDirectory/nightlies/experimentalWebArea/nicos_web_areaCMAKE64BS6G49TrgOpt/NICOS_Log_rel_3/nicos_rpm_build.html
>>>> 
>>>> Note that when I tried to build the project in a build area with a shorter 
>>>> path, then the RPM building succeeded. Just because by chance in that case 
>>>> in the expression
>>>> 
>>>> string(SUBSTRING "${SYMLINK_POINT_}" ${WDR_LEN_} -1 SYMLINK_POINT_WD_)
>>>> 
>>>> the work directory length was shorter than the length of the path outside 
>>>> of the project.
>>>> 
>>>> Of course this is the code that we're talking about:
>>>> 
>>>> https://cmake.or

Re: [cmake-developers] CPackRPM not dealing correctly with symlinks

[Attila Krasznahorkay]

Hi Domen,

Unfortunately I can't seem to create an easy-to-package example for the issue. 
Since it seems that the file given to the install(...) command has to be in a 
"very different place" than the source or binary directories for the issue to 
come up. (My guess is that if the file shares some of its path with the build 
directory, CPackRPM uses a different method for dealing with it than if the two 
paths don't share any prefix.)

In our case some files are picked up from a network drive, while the build 
happens (naturally) on a local drive. I can reproduce the issue with a 
CMakeLists.txt file like:

cmake_minimum_required( VERSION 2.8 )
project( CPackRPMLinkProblem )

install( FILES /afs/cern.ch/.../some_link.txt DESTINATION . )

set( CPACK_PACKAGE_RELOCATABLE TRUE )
include( CPack )

As long as the build directory's path name ends up being longer than the path 
name of the file specified in the install(...) command, the RPM building fails. 
As it does for instance here:

http://atlas-computing.web.cern.ch/atlas-computing/links/distDirectory/nightlies/experimentalWebArea/nicos_web_areaCMAKE64BS6G49AnlOpt/NICOS_Log_rel_4/nicos_rpm_build.html

Cheers,
   Attila

> On 23 Mar 2016, at 15:57, Domen Vrankar <domen.vran...@gmail.com> wrote:
> 
> As a workaround you could set files that you would like to be excluded
> from symlink relocation with CPACK_RPM_USER_FILELIST or
> CPACK_RPM__USER_FILELIST.
> 
> I'll have a look at how this could be solved for later versions of CPack.
> Do I understand correctly that those errors occur when a symlink is
> pointing to another simlink outside your project?
> Could you please provide a minimal example of all your cases?
> 
> Thanks,
> Domen
> 
> 
> 2016-03-23 14:13 GMT+01:00 Attila Krasznahorkay
> <attila.krasznahor...@gmail.com>:
>> Hi Brad,
>> 
>> I did. Then I get:
>> 
>> CMake Error at 
>> /afs/cern.ch/work/k/krasznaa/public/cmake/3.5.0/share/cmake-3.5/Modules/CPackRPM.cmake:981
>>  (string):
>> string begin index: 164 is out of range 0 - 156
>> Call Stack (most recent call first):
>> /afs/cern.ch/work/k/krasznaa/public/cmake/3.5.0/share/cmake-3.5/Modules/CPackRPM.cmake:1625
>>  (cpack_rpm_prepare_install_files)
>> /afs/cern.ch/work/k/krasznaa/public/cmake/3.5.0/share/cmake-3.5/Modules/CPackRPM.cmake:1787
>>  (cpack_rpm_generate_package)
>> 
>> You can find the full output here:
>> 
>> http://atlas-computing.web.cern.ch/atlas-computing/links/distDirectory/nightlies/experimentalWebArea/nicos_web_areaCMAKE64BS6G49TrgOpt/NICOS_Log_rel_3/nicos_rpm_build.html
>> 
>> Note that when I tried to build the project in a build area with a shorter 
>> path, then the RPM building succeeded. Just because by chance in that case 
>> in the expression
>> 
>> string(SUBSTRING "${SYMLINK_POINT_}" ${WDR_LEN_} -1 SYMLINK_POINT_WD_)
>> 
>> the work directory length was shorter than the length of the path outside of 
>> the project.
>> 
>> Of course this is the code that we're talking about:
>> 
>> https://cmake.org/gitweb?p=cmake.git;a=blob;f=Modules/CPackRPM.cmake;h=7ffec136deabb8f28d6293cdc96e43cd4a2af70d;hb=HEAD#l994
>> 
>> Cheers,
>> Attila
>> 
>>> On 23 Mar 2016, at 13:50, Brad King <brad.k...@kitware.com> wrote:
>>> 
>>> On 03/23/2016 08:44 AM, Attila Krasznahorkay wrote:
>>>> CMake Error at /afs/cern.ch/sw/lcg/contrib/CMake/3.3.2/...
>>> 
>>> Please try with CMake 3.5.
>>> 
>>> -Brad
>>> 
>> 

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Patch to only consider build dependencies between files in the source directory

[Attila Krasznahorkay]

Hi Brad,

Thanks! Looks good.

Cheers,
   Attila

> On 23 Mar 2016, at 19:05, Brad King <brad.k...@kitware.com> wrote:
> 
> On 03/22/2016 08:23 AM, Attila Krasznahorkay wrote:
>> Here is my next attempt. ;-) Hopefully I'm at least getting closer...
> 
> Thanks.  Applied with minor tweaks:
> 
> Makefile: Optionally scan only source and build trees for dependencies
> https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b1e1aa1e
> 
> I also added a test case and release note:
> 
> Tests: Add test for CMAKE_DEPENDS_IN_PROJECT_ONLY variable
> https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=52540245
> 
> Help: Add notes for topic 'cmake-depend-in-project-only'
> https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b06e17da
> 
> -Brad

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] CPackRPM not dealing correctly with symlinks

[Attila Krasznahorkay]

Hi Brad,

I did. Then I get:

CMake Error at 
/afs/cern.ch/work/k/krasznaa/public/cmake/3.5.0/share/cmake-3.5/Modules/CPackRPM.cmake:981
 (string):
string begin index: 164 is out of range 0 - 156 
Call Stack (most recent call first): 
/afs/cern.ch/work/k/krasznaa/public/cmake/3.5.0/share/cmake-3.5/Modules/CPackRPM.cmake:1625
 (cpack_rpm_prepare_install_files) 
/afs/cern.ch/work/k/krasznaa/public/cmake/3.5.0/share/cmake-3.5/Modules/CPackRPM.cmake:1787
 (cpack_rpm_generate_package)

You can find the full output here:

http://atlas-computing.web.cern.ch/atlas-computing/links/distDirectory/nightlies/experimentalWebArea/nicos_web_areaCMAKE64BS6G49TrgOpt/NICOS_Log_rel_3/nicos_rpm_build.html

Note that when I tried to build the project in a build area with a shorter 
path, then the RPM building succeeded. Just because by chance in that case in 
the expression

string(SUBSTRING "${SYMLINK_POINT_}" ${WDR_LEN_} -1 SYMLINK_POINT_WD_)

the work directory length was shorter than the length of the path outside of 
the project.

Of course this is the code that we're talking about:

https://cmake.org/gitweb?p=cmake.git;a=blob;f=Modules/CPackRPM.cmake;h=7ffec136deabb8f28d6293cdc96e43cd4a2af70d;hb=HEAD#l994

Cheers,
 Attila

> On 23 Mar 2016, at 13:50, Brad King <brad.k...@kitware.com> wrote:
> 
> On 03/23/2016 08:44 AM, Attila Krasznahorkay wrote:
>> CMake Error at /afs/cern.ch/sw/lcg/contrib/CMake/3.3.2/...
> 
> Please try with CMake 3.5.
> 
> -Brad
> 

-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] CPackRPM not dealing correctly with symlinks

[Attila Krasznahorkay]

Dear All,

Not sure what's the best way to post this issue, so I thought I'd send around 
an e-mail first.

We've been struggling with some RPM building errors in some of our projects for 
a while now. Finally I was able to understand what the cause of the issue is.

In some cases we put symbolic links into the installation area of our projects 
that themselves point to other symbolic links, outside of the project. When 
this happens, the RPM building dies with a message like:

CMake Error at 
/afs/cern.ch/sw/lcg/contrib/CMake/3.3.2/Linux-x86_64/share/cmake-3.3/Modules/CPackRPM.cmake:906
 (string):
string begin index: 164 is out of range 0 - 156 
Call Stack (most recent call first): 
/afs/cern.ch/sw/lcg/contrib/CMake/3.3.2/Linux-x86_64/share/cmake-3.3/Modules/CPackRPM.cmake:1535
 (cpack_rpm_prepare_install_files) 
/afs/cern.ch/sw/lcg/contrib/CMake/3.3.2/Linux-x86_64/share/cmake-3.3/Modules/CPackRPM.cmake:1697
 (cpack_rpm_generate_package)

For some of the files this is actually a bug on our end, as we need to make 
sure that we install actual files with the project, not a symlink to a file.

But I also ran into another case where avoiding CPackRPM to deal with such a 
link-to-a-link setup is not easily avoidable. Does anyone have an idea how the 
CPackRPM.cmake code should be protected against such issues? Printing warnings 
about such files, saying that the produced RPM will not be fully relocatable, 
is fine. We just need to avoid outright errors during the RPM building.

Cheers,
 Attila
-- 

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] Patch to only consider build dependencies between files in the source directory

[Attila Krasznahorkay]

Dear Both,

Here is my next attempt. ;-) Hopefully I'm at least getting closer...

Cheers,
  Attila



0001-Introducing-the-CMAKE_DEPENDS_IN_PROJECT_ONLY-variab.patch
Description: Binary data


> On 18 Mar 2016, at 16:57, David Cole <dlrd...@aol.com> wrote:
> 
> Brad's point with "/" or null terminator was that the directory name
> **must** be the directory itself, or a sub-directory of the one in
> question.
> 
> i.e.
> 
> if it's "my/src"
> 
> then it should either be exactly "my/src" or "my/src/someSubDir" , not
> "my/srcSiblingDir"
> 
> 
> 
> 
> On Fri, Mar 18, 2016 at 11:52 AM, Attila Krasznahorkay
> <attila.krasznahor...@gmail.com> wrote:
>> Hi Brad,
>> 
>>>> +  // If it's an absolute path, check if it starts with the source
>>>> +  // direcotory:
>>>> +  return ( ( path.find( SourceDir ) != 0 ) &&
>>>> +   ( path.find( BinaryDir ) != 0 ) );
>>> 
>>> Please look at using strncmp and a check that the following character
>>> is a nul terminator or '/'.  Otherwise an external location with
>>> a common prefix may be mistaken for part of the project.
>> 
>> Not sure what scenario you have in mind here. :-/ std::string::find should 
>> only return 0 if the source directory path or binary directory path is what 
>> the evaluated path begins with. Why should we worry what the path continues 
>> with?
>> 
>> I was wondering about possibly using strncmp, but thought that 
>> performance-wise std::string::find should be fine as well here.
>> 
>> I'm not at all against changing the code, I just don't understand yet what 
>> setup the current code would not handle correctly.
>> 
>>> Also please add documentation in a
>>> 
>>> Help/variable/CMAKE_DEPENDS_IN_PROJECT_ONLY.rst
>>> 
>>> file and update Help/manual/cmake-variables.7.rst to reference it.
>> 
>> Will do. Was just not sure where to add this documentation.
>> 
>> Cheers,
>>Attila
>> --
>> 
>> 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

Re: [cmake-developers] Patch to only consider build dependencies between files in the source directory

[Attila Krasznahorkay]

Hi Brad,

Attached is a new attempt. It seems to work correctly in my tests with the 
Makefile generator. (Which, to be fair, is the only generator that we use in 
production mode at the moment...)

Cheers,
Attila


0001-CMAKE_DEPENDS_IN_PROJECT_ONLY-feature-addition.patch
Description: Binary data


> On 15 Mar 2016, at 19:13, Brad King <brad.k...@kitware.com> wrote:
> 
> On 03/15/2016 10:48 AM, Attila Krasznahorkay wrote:
>> https://cmake.org/pipermail/cmake-developers/2015-December/027197.html
>> 
>> With the following patch, when setting the CMAKE_ONLY_IN_SOURCE_DEPENDENCIES
>> variable to 1/ON/TRUE, this file size goes down to just a few kilobytes.
>> Speeding up our build noticeably.
> 
> Thanks.  As Ben pointed out in the original thread the build tree should
> be included as well.  Perhaps a name like
> 
>  CMAKE_DEPENDS_IN_PROJECT_ONLY
> 
> could be used to indicate that it includes only dependencies in the project
> directories (source or build tree).
> 
>> As far as I can see, the "cmake -E cmake_depends" call is only used by
>> the Makefile generator at the moment. So I only taught that generator
>> about this new variable.
> 
> The Makefile generator is the only one for which CMake takes responsibility
> for implicit dependency scanning.
> 
>> I just didn't see what I should do in the Ninja generator for instance
>> to apply this setting. Even though I would be very interested in implementing
>> the feature in that generator as well.
> 
> The Ninja generator uses the compiler's information about dependencies
> as generated by options like `gcc -MD`.  Since that occurs along with
> the compilation there is little cost to including all dependencies
> except for stat during rebuilds.  See discussion here:
> 
>  https://cmake.org/Bug/view.php?id=14914
> 
> about the opposite use case (including system dependencies instead of
> excluding them).
> 
>> +  infoFileStream
>> +<< "set(CMAKE_ONLY_IN_SOURCE_DEPENDENCIES "
>> +<< ( this->Makefile->IsOn( "CMAKE_ONLY_IN_SOURCE_DEPENDENCIES" ) ?
>> + "1" : "0" )
>> +<< ")\n";
> 
> Rather than communicating this to the dependency scanning step and
> doing the filtering there, please look at applying the filter during
> generation of CMAKE__TARGET_INCLUDE_PATH.
> 
> Thanks,
> -Brad
> 

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Patch to only consider build dependencies between files in the source directory

[Attila Krasznahorkay]

Hi Brad,

>> +  // If it's an absolute path, check if it starts with the source
>> +  // direcotory:
>> +  return ( ( path.find( SourceDir ) != 0 ) &&
>> +   ( path.find( BinaryDir ) != 0 ) );
> 
> Please look at using strncmp and a check that the following character
> is a nul terminator or '/'.  Otherwise an external location with
> a common prefix may be mistaken for part of the project.

Not sure what scenario you have in mind here. :-/ std::string::find should only 
return 0 if the source directory path or binary directory path is what the 
evaluated path begins with. Why should we worry what the path continues with?

I was wondering about possibly using strncmp, but thought that performance-wise 
std::string::find should be fine as well here.

I'm not at all against changing the code, I just don't understand yet what 
setup the current code would not handle correctly.

> Also please add documentation in a
> 
>  Help/variable/CMAKE_DEPENDS_IN_PROJECT_ONLY.rst
> 
> file and update Help/manual/cmake-variables.7.rst to reference it.

Will do. Was just not sure where to add this documentation.

Cheers,
Attila
-- 

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] Patch to only consider build dependencies between files in the source directory

[Attila Krasznahorkay]

Hi Brad,

All valid points. Will try to make a new patch today.

Cheers,
   Attila

> On 15 Mar 2016, at 19:13, Brad King <brad.k...@kitware.com> wrote:
> 
> On 03/15/2016 10:48 AM, Attila Krasznahorkay wrote:
>> https://cmake.org/pipermail/cmake-developers/2015-December/027197.html
>> 
>> With the following patch, when setting the CMAKE_ONLY_IN_SOURCE_DEPENDENCIES
>> variable to 1/ON/TRUE, this file size goes down to just a few kilobytes.
>> Speeding up our build noticeably.
> 
> Thanks.  As Ben pointed out in the original thread the build tree should
> be included as well.  Perhaps a name like
> 
>  CMAKE_DEPENDS_IN_PROJECT_ONLY
> 
> could be used to indicate that it includes only dependencies in the project
> directories (source or build tree).
> 
>> As far as I can see, the "cmake -E cmake_depends" call is only used by
>> the Makefile generator at the moment. So I only taught that generator
>> about this new variable.
> 
> The Makefile generator is the only one for which CMake takes responsibility
> for implicit dependency scanning.
> 
>> I just didn't see what I should do in the Ninja generator for instance
>> to apply this setting. Even though I would be very interested in implementing
>> the feature in that generator as well.
> 
> The Ninja generator uses the compiler's information about dependencies
> as generated by options like `gcc -MD`.  Since that occurs along with
> the compilation there is little cost to including all dependencies
> except for stat during rebuilds.  See discussion here:
> 
>  https://cmake.org/Bug/view.php?id=14914
> 
> about the opposite use case (including system dependencies instead of
> excluding them).
> 
>> +  infoFileStream
>> +<< "set(CMAKE_ONLY_IN_SOURCE_DEPENDENCIES "
>> +<< ( this->Makefile->IsOn( "CMAKE_ONLY_IN_SOURCE_DEPENDENCIES" ) ?
>> + "1" : "0" )
>> +<< ")\n";
> 
> Rather than communicating this to the dependency scanning step and
> doing the filtering there, please look at applying the filter during
> generation of CMAKE__TARGET_INCLUDE_PATH.
> 
> Thanks,
> -Brad
> 

-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] Patch to only consider build dependencies between files in the source directory

[Attila Krasznahorkay]

Dear All,

I've already talked about this a bit back in December.

https://cmake.org/pipermail/cmake-developers/2015-December/027197.html

I looked at this issue today again, as in our builds we can be seriously 
hampered by "cmake -E cmake_depends" calls. And then, by the huge dependency 
trees that these calls create. To give you a sense of the extent of the issue: 
While compiling just a few files against our full software build (we have a 
relatively complicated build setup allowing us to build small parts of our code 
against a nightly build of our full release), I get a depend.cmake file almost 
9 MBs large.

With the following patch, when setting the CMAKE_ONLY_IN_SOURCE_DEPENDENCIES 
variable to 1/ON/TRUE, this file size goes down to just a few kilobytes. 
Speeding up our build noticeably.

As far as I can see, the "cmake -E cmake_depends" call is only used by the 
Makefile generator at the moment. So I only taught that generator about this 
new variable. I just didn't see what I should do in the Ninja generator for 
instance to apply this setting. Even though I would be very interested in 
implementing the feature in that generator as well.

I know that the code is not at all generic enough right now. But even at 
limited functionality, it may already be useful to a few other people as well.

Cheers,
   Attila



0001-CMAKE_ONLY_IN_SOURCE_DEPENDENCIES-feature-addition.patch
Description: Binary data
-- 

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] C++11 only for a specified subdirectory

[Attila Krasznahorkay]

Hi Roman,

If you only set

set( CMAKE_CXX_STANDARD 11 )

in that subdirectory, then this should happen automatically. (Since the 
variable will not be visible as soon as you go out of the scope of this 
"subdirectory".)

Otherwise you could just set the CXX_STANDARD property on the targets that 
should be built in C++11 mode.

https://cmake.org/cmake/help/v3.1/prop_tgt/CXX_STANDARD.html

Cheers,
Attila

> On 04 Mar 2016, at 14:20, Roman Wüger  wrote:
> 
> Hi,
> 
> is it possible to activate C++11 only for a subdirectory?
> 
> Regards
> Roman
> -- 
> 
> 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

Re: [CMake] CMake 3.5-CMAKE_BINARY_DIR is set to ${CMAKE_SOURCE_DIR} when calling add_subdirectory?

[Attila Krasznahorkay]

Hi Gerry,

Setting these variables by hand sounds quite dangerous. I'm not sure how much 
this is meant to be supported.

There is a much more "native" way of doing this. You could do:

add_subdirectory( ${source_dir} ${binary_dir} )

, where "source_dir" would be the source directory relative to 
${CMAKE_SOURCE_DIR}, and "binary_dir" could be any absolute path of your 
choice. You could for instance set it to:

set( binary_dir "${CMAKE_BINARY_DIR}/${source_dir}/build" )

Although all in all, this directory organisation of yours seems pretty 
"forced". :-/

Cheers,
  Attila

P.S. When calling add_subdirectory like this, ${CMAKE_CURRENT_BINARY_DIR} is 
definitely set correctly in the subdirectory. But ${CMAKE_BINARY_DIR} will 
still be the one that CMake sets automatically. You should really not be trying 
to modify this latter value.

> On 22 Feb 2016, at 05:45, Gerry Fan  wrote:
> 
> before calling add_subdirectory, set up 2 variables like:
>   set(CMAKE_SOURCE_DIR /Users/test/proj/fplbase)
>   set(CMAKE_BINARY_DIR  /Users/test/proj/fplbase/build)
>   add_subdirectory(${sdl_dir} “/Users/test/proj/fplbase/obj”)
>   
> In module ${dl_dir}’s CMakeLists.txt, at the beginning, it has:
> if(${CMAKE_SOURCE_DIR} STREQUAL ${CMAKE_BINARY_DIR})
>   message(FATAL_ERROR "Prevented in-tree built. Please create a build 
> directory outside of the SDL source code and call cmake from there”)
> endif()
> 
> Somehow the above error is always triggered, does not matter what I set 
> CMAKE_BINARY_DIR to. when printing out CMAKE_SOURCE_DIR and CMAKE_BINARY_DIR, 
> CMAKE_BINARY_DIR is set to the same path as CMAKE_SOURCE_DIR ( 
> /Users/test/proj/fplbase ) in module ${dl_dir}
> 
> this only  happens with CMake 3.5-RCx, not happening with previous make 
> versions ( 3.4, 3.3 ). 
> 
> seems this checkin began to have it:
> commit c4e1bc6ed24d57ef3136756802aa575642927ff1
> Merge: f9cc671 0aef6f2
> Merge branch ‘release
> 
> 
> Is this a bug?
> 
> thank you
> 
> -- 
> 
> 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] CMAKE_MODULE_PATH ignored

[Attila Krasznahorkay]

Hi,

I myself use statements like:

list( INSERT CMAKE_MODULE_PATH 0 ${CMAKE_SOURCE_DIR}/modules )

at the beginning of my main CMakeLists.txt file, and it works exactly as one 
would expect. I also override some CMake provided modules like this.

Cheers,
Attila

> On 08 Feb 2016, at 20:22, Micha Hergarden  wrote:
> 
> On 08/02/16 19:35, Alain Miniussi wrote:
>> On 08/02/2016 18:43, Alain Miniussi wrote:
>>> 
>>> Hi,
>>> 
>>> I am trying to fix FindHDF5.cmake (support for HDF5_ROOT is broken,
>>> only environment variable is supported and it will be eventually
>>> probably ignored in find_program).
>>> 
>>> To that end, I'd like to copy it in my source tree and use that
>>> version instead of the one in /usr/shared/cmake.
>>> 
>>> According to the documentation, all I have to do is to indicate the
>>> search directory for the FindXXX.cmak files through CMAKE_MODULE_PATH.
>>> 
>>> From the cmake --trace:
>>> 
>>> /../trunk/CMakeLists.txt(49):  message(status  CMAKE_MODULE_PATH:
>>> ${CMAKE_MODULE_PATH} )
>>> ## This is the correct PATH, containing the FindHDF5.cmake file
>>> status CMAKE_MODULE_PATH:
>>> /scratch/alainm/view/seiscope/codes/3D_Acoustic/FFWI/trunk/tools/build/
>>> ## Next line:
>>> /.../trunk/CMakeLists.txt(50):  find_package(HDF5 COMPONENTS CXX
>>> Fortran )
>>> ## Wrong path selected:
>>> /usr/share/cmake/Modules/FindHDF5.cmake(63): 
>>> include(${CMAKE_CURRENT_LIST_DIR}/SelectLibraryConfigurations.cmake )
>>> 
>>> How do I tell cmake I want *my* path to be selected ?
>>> 
>>> Thanks
>>> 
>> 
>> Renaming FindHDF5.cmake in FindH5.cmake (or whatever is not present in
>> the global cmake install) helps, but then I also need to replicate all
>> dependencies (FindPackageMessage.cmake,
>> SelectLibraryConfigurations.cmake...), shouldn't cmake look in the
>> /usr/shar/cmake/... for those ?
>> 
>> Thanks
>> 
>> Alain
>> 
> How do you set CMAKE_MODULE_PATH exactly? I used to have a modified
> module in my source archive and prepend that dir to the variable:
> set(CMAKE_MODULE_PATH "${CMAKE_CURRENT_SOURCE_DIR}/cmake"
> ${CMAKE_MODULE_PATH})
> 
> Regards,
> Micha
> 
> -- 
> 
> 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] Stopping CPack from compiling python files

[Attila Krasznahorkay]

Thanks for the suggestions! I'll give it a try.

Cheers,
Attila

> On 28 Jan 2016, at 14:07, Domen Vrankar  wrote:
> 
>> Not sure how we can disable such script call from CPackRPM unless adding the
>> extra feature to call
>> rpm/rpmbuild wiht appropriate option. May be you can try to fill the
>> CPACK_RPM_SPEC_MORE_DEFINE variable
>> with appropriate macro redefining "__os_install_post".
>> 
>> This would be more like a hack than a solution.
> 
> As far as I can tell from links such as
> https://www.redhat.com/archives/rpm-list/2007-November/msg00020.html
> and
> http://www.math-linux.com/linux/rpm/article/how-to-turn-off-avoid-brp-python-bytecompile-script-in-a-spec-file
> there is no non hack solution for this so even if we'd put it in
> CPackRPM it would be a hackish workaround.
> 
> Content from the second link might be the right candidate for
> CPACK_RPM_SPEC_MORE_DEFINE (haven't tested it).
> 
> set(CPACK_RPM_SPEC_MORE_DEFINE "%global __os_install_post %(echo
> '%{__os_install_post}' | sed -e
> 's!/usr/lib[^[:space:]]*/brp-python-bytecompile[[:space:]].*$!!g')")
> 
> 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] Stopping CPack from compiling python files

[Attila Krasznahorkay]

Dear All,

This should be a simple question, but somehow I don't seem to find an answer to 
it with Google.

Our projects have a lot of python files in them. Many of which are not simple 
python files. They are files that need our software to interpret them. So CPack 
should just leave them alone.

But CPack is trying to do something "smart". Which I'd like to turn off. Since 
in all of our rpmbuild.err files I see lines like:

+ /usr/lib/rpm/check-buildroot
+ /usr/lib/rpm/redhat/brp-compress
+ /usr/lib/rpm/redhat/brp-strip /usr/bin/strip
+ /usr/lib/rpm/redhat/brp-strip-static-archive /usr/bin/strip
+ /usr/lib/rpm/redhat/brp-strip-comment-note /usr/bin/strip /usr/bin/objdump
+ /usr/lib/rpm/brp-python-bytecompile
+ /usr/lib/rpm/redhat/brp-python-hardlink
+ /usr/lib/rpm/redhat/brp-java-repack-jars
warning: Installed (but unpackaged) file(s) found:
...
   
/usr/AtlasCore/21.0.0/InstallArea/x86_64-slc6-gcc49-opt/jobOptions/AthAnalysisBaseComps/SuppressLogging.pyc
   
/usr/AtlasCore/21.0.0/InstallArea/x86_64-slc6-gcc49-opt/jobOptions/AthAnalysisBaseComps/SuppressLogging.pyo
...

(And in some projects the RPM building actually fails, seemingly because of 
problems with compiling some of these files.)

I guess it's the "brp-python-bytecompile" command that's responsible for doing 
this. Is there an easy way that I can tell CPackRPM to forget about this step? 
I would really like to avoid writing a custom spec file if I can...

Cheers,
Attila
-- 

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] Creating RPMs from failing projects with CPack

[Attila Krasznahorkay]

Hi Domen,

Thanks a lot for the tip! I'll give it a try. (The "monolithic limitation" 
should not be an issue for us. We do build single RPMs for our projects.)

Cheers,
Attila

> On 21 Jan 2016, at 00:49, Domen Vrankar <domen.vran...@gmail.com> wrote:
> 
>> I have a slightly unusual question (I guess). Is it possible somehow to 
>> force CPack to produce RPM files from projects that have build problems?
>> 
>> We use CMake in our nightly build system to test the latest changes in our 
>> software. When a build problem occurs we don't want the whole build to fail. 
>> To this end, we run the build with:
>> 
>> make -k
>> make -k install/fast
>> 
>> This second target executes the installation no matter what. (We set all our 
>> build results as "optional installations".) So that at least the "successful 
>> part" of the build would become visible on a shared filesystem.
>> 
>> Now, I'd like to do something similar with CPack. To make it behave like 
>> "install/fast" does. All in all, I'd like to tell it to use this 
>> "install/fast" target while creating the package instead of the "install" 
>> target. Is there any way of making this happen?
> 
> I don't know of any clean way to do this but you could write an
> install script (let's name it install_k.sh):
> 
> #!/bin/bash
> make -k install/fast
> exit 0
> 
> Then your would add two CPACK variables to your CMakeLists.txt:
> 
> #set(CPACK_RPM_COMPONENT_INSTALL "ON") <- I'll explain this commented line 
> later
> set(CPACK_INSTALL_CMAKE_PROJECTS "")
> set(CPACK_INSTALL_COMMANDS "${CMAKE_CURRENT_SOURCE_DIR}/install_k.sh")
> 
> And instead of packaging with "make package" command execute "cpack -G RPM".
> 
> However there is an additional problem that this hack only works for
> monolithic packages (that's why I commented out
> CPACK_RPM_COMPONENT_INSTALL in example above) so you will have to
> disable component packages generation if you are using it.
> 
> Regards,
> Domen
> 
> 2016-01-20 11:26 GMT+01:00 Attila Krasznahorkay
> <attila.krasznahor...@gmail.com>:
>> Dear All,
>> 
>> I have a slightly unusual question (I guess). Is it possible somehow to 
>> force CPack to produce RPM files from projects that have build problems?
>> 
>> We use CMake in our nightly build system to test the latest changes in our 
>> software. When a build problem occurs we don't want the whole build to fail. 
>> To this end, we run the build with:
>> 
>> make -k
>> make -k install/fast
>> 
>> This second target executes the installation no matter what. (We set all our 
>> build results as "optional installations".) So that at least the "successful 
>> part" of the build would become visible on a shared filesystem.
>> 
>> Now, I'd like to do something similar with CPack. To make it behave like 
>> "install/fast" does. All in all, I'd like to tell it to use this 
>> "install/fast" target while creating the package instead of the "install" 
>> target. Is there any way of making this happen?
>> 
>> Cheers,
>>  Attila
>> --
>> 
>> 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

[CMake] Creating RPMs from failing projects with CPack

[Attila Krasznahorkay]

Dear All,

I have a slightly unusual question (I guess). Is it possible somehow to force 
CPack to produce RPM files from projects that have build problems?

We use CMake in our nightly build system to test the latest changes in our 
software. When a build problem occurs we don't want the whole build to fail. To 
this end, we run the build with:

make -k
make -k install/fast

This second target executes the installation no matter what. (We set all our 
build results as "optional installations".) So that at least the "successful 
part" of the build would become visible on a shared filesystem.

Now, I'd like to do something similar with CPack. To make it behave like 
"install/fast" does. All in all, I'd like to tell it to use this "install/fast" 
target while creating the package instead of the "install" target. Is there any 
way of making this happen?

Cheers,
  Attila
-- 

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] adding parts of build log to dashboard.

[Attila Krasznahorkay]

Hi Rashad,

It may not be the perfect way of doing it, but I attach build log files as 
"notes". With something like:

set( CTEST_NOTES_FILES ${CTEST_BINARY_DIRECTORY}/BuildLogs/log1.log ... )
ctest_submit( PARTS Build Notes )

(I actually do something rather more complicated. I split the build into 
sub-projects, which are built in parallel, producing subproject-specific build 
logs in parallel. In the end I upload all the build results one by one for each 
of the sub-projects. I can send you my NightlyBuild.cmake file if you're 
interested...)

Cheers,
Attila

> On 07 Jan 2016, at 14:51, Rashad Kanavath  wrote:
> 
> Hello,
> 
> How can I include part of my build log to cdash output. Currently cdash 
> pickup build errors and warnings. 
> 
> In the build summary, if there is no build log attached. I think this is 
> intentional given the size of build log for some projects.
> 
> What I would like to know is , if there is way I can put some logs into build 
> summary page via some special cmake settings. I don't may be setting a cmake 
> var ?
> 
> My situation is I have a set of add_custom_targets that I used to make 
> packages. they produce various ouputs such as processing abc.dll, creating 
> zip archive, adding files to archive etc..
> 
> Is there a way I can include them into the build summary ?
> 
> 
> 
> -- 
> Regards,
>Rashad
> -- 
> 
> 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] Get target name from command line for IF statement

[Attila Krasznahorkay]

Hi Yann,

I have no idea what LINKER_SCATTER_FILE does, but...

if( TARGET  )

is a check that will evaluate to true if a target named  *exists*. In this 
configuration neither "target_1" or "target_2" exist at the point when you run 
this check. So LINKER_SCATTER_FILE will always be set to "file_2".

I think you're mixing what happens when configuring your build, and when 
actually executing it. In this setup you seem to always want to build both 
target_1 and target_2. So you'll need to set some property on these targets to 
assign the different "scatter files" to them. (I have absolutely no idea what a 
"scatter file" is supposed to be...)

Could you elaborate on what you're really trying to do?

Cheers,
Attila

> On 30 Dec 2015, at 11:29, yann suisini  wrote:
> 
> Hi,
> 
> I have a cmake file with 2 targets defined inside.
> For each target I have to specify a different scatter file for my linker
> 
> so I want to use :
> if (TARGET target_1)
>   SET (LINKER_SCATTER_FILE file_1)
> else ()
>   SET (LINKER_SCATTER_FILE file_2)
> endif ()
> 
> add_executable(target_1 ${srcs_target_1})
> add_executable(target_2 ${srcs_target_2})
> 
> 
> But if I'm calling cmake from my IDE to build my target using the --target 
> command line option
> does it set the TARGET variable ? If not the case how I can link the targer 
> name from the command line to my IF statement ?
> 
> Regards,
> 
> Yann.
> 
> 
> 
> 
> -- 
> 
> 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] I can not set CMAKE_BUILD_TYPE in CMakeList.txt

[Attila Krasznahorkay]

Hi Isaac,

ccmake will only allow you to modify cache variables. When you call

set( CMAKE_BUILD_TYPE RelWithDebInfo )

, this creates a local variable in your CMakeLists.txt file. This way it should 
*always* override whatever you set on the command line, or as a cache variable.

If you want to set the default value to RelWithDebInfo, but allow the user to 
override it either with ccmake or a command line argument, you should do 
something like:

set( CMAKE_BUILD_TYPE RelWithDebInfo CACHE STRING "Build type" )

At least I think it should work like this...

Cheers,
  Attila

> On 05 Jan 2016, at 08:11, Isaac Ge  wrote:
> 
> Hi anyone, I find the `set(CMAKE_BUILD_TYPE RelWithDebInfo)` in CMakeList.txt 
> does not work, because the actual build type show by ccmake is empty. So I 
> have to enter the correct build type in ccmake or add command argument `-D 
> CMAKE_BUILD_TYPE=RelWithDebInfo` while cmake.
> 
> Any idea? Thank you!
> -- 
> 
> 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] organizing source files with CMake

[Attila Krasznahorkay]

Hi Victor,

(Without a name I don't have anything better to go on here...)

You could do the following in your subdirectory's CMakeLists.txt file:

set( SOURCE ${SOURCE} ${CMAKE_CURRENT_SOURCE_DIR}/file1.cpp ... )
set( SOURCE ${SOURCE} PARENT_SCOPE )

The second line will make sure that the variable is updated in the parent's 
scope (the main CMakeLists.txt file) as well.

Cheers,
Attila

> On 17 Dec 2015, at 16:27, Victorious  wrote:
> 
> Hi,
>  
> I’d like to have all my source files in an src folder. The src folder may 
> have .cpp/.h files, and can also have subfolders. 
>  
> This is how I’ve been doing it, but it only seems to work with files in the 
> src folder (not sure how to extend this to subfolders inside src).
> Src/cmake list.txt:
>  
> set(SOURCE
>${SOURCE}
>${CMAKE_CURRENT_SOURCE_DIR}/file1.cpp
>${CMAKE_CURRENT_SOURCE_DIR}/file2.cpp
> PARENT_SCOPE
> )
>  
> set(HEADERS
>${HEADERS}
>${CMAKE_CURRENT_SOURCE_DIR}/file1.h
>${CMAKE_CURRENT_SOURCE_DIR}/file2.h
>PARENT_SCOPE
> add_subdirectory("subdir1")
>  
> Src/subdir1’s cmake list looks similar minus the last line. Then in the top 
> cmake list.txt,
> add_executable("app" ${SOURCE} ${HEADERS})
>  
> A follow-up question: is it possible to do this without specifying each file 
> manually?
>  
> Thanks
> -- 
> 
> Powered by www.kitware.com
> 
> Please keep messages on-topic and check the CMake FAQ at: 
> http://www.cmake.org/Wiki/CMake_FAQ
> 
> Kitware offers various services to support the CMake community. For more 
> information on each offering, please visit:
> 
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
> 
> Visit other Kitware open-source projects at 
> http://www.kitware.com/opensource/opensource.html
> 
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake

-- 

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] Restriction on target types for GraphViz dependency graph generation

[Attila Krasznahorkay]

Hi Andrey,

I would be extremely happy with an extension to this functionality.

Right now I have way too many targets in my projects to make good sense of them 
if all of them are put into a single graph. If I would be able to specify that 
I'd like to see the connections between all the targets with names ".*Pkg$" for 
instance, that could be very nice.

Cheers,
   Attila

> On 16 Dec 2015, at 05:20, Andrey Mishchenko  wrote:
> 
> Hi,
> 
> I noticed that the automatic dependency graph generation in CMake targeting 
> GraphViz only considers targets of certain types. In particular, it only adds 
> nodes for executables and shared, static, and module libraries.
> 
> Is this deliberate?
> 
> If I submit a patch extending this functionality to (optionally, via 
> configuration variables) work with more target types, would it be received 
> well?
> 
> Andrey Mishchenko
> -- 
> 
> 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

Re: [cmake-developers] [CMake] How to set _default_ timeout for the ctest command? (fwd)

[Attila Krasznahorkay]

Hi Alan,

Are you just looking for the TIMEOUT property on the tests?

https://cmake.org/cmake/help/v3.0/command/set_tests_properties.html

This is something that I managed to find with the most basic google-ing myself. 
:-/ And I use it like:

set_tests_properties( ${testName}Test PROPERTIES TIMEOUT 120 )

Or would you like to be able to set some global property/variable that would 
set the default timeout for all the created tests without you having to set 
these things individually? (I just wrote a wrapper function to set up all my 
tests in the way that I wanted to.)

Best,
   Attila

> On Dec 14, 2015, at 9:36 PM, Alan W. Irwin  wrote:
> 
> I would appreciate it if a CMake developer who is familiar with the CTest 
> timeout
> logic would answer my question below that was addressed to "@CMake 
> developers:".
> 
> Without such an answer (even if the conclusion is there is no way for
> an individual software package such as lapack to set a different
> _default_ timeout for CTest other than 1500 seconds), I will not be
> able to figure out what to advise the lapack developers.
> 
> Alan
> 
> __
> Alan W. Irwin
> 
> Astronomical research affiliation with Department of Physics and Astronomy,
> University of Victoria (astrowww.phys.uvic.ca).
> 
> Programming affiliations with the FreeEOS equation-of-state
> implementation for stellar interiors (freeeos.sf.net); the Time
> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
> software package (plplot.sf.net); the libLASi project
> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
> and the Linux Brochure Project (lbproject.sf.net).
> __
> 
> Linux-powered Science
> __
> 
> -- Forwarded message --
> Date: Wed, 9 Dec 2015 19:06:00 -0800 (PST)
> From: Alan W. Irwin 
> To: Marcel Loose 
> Cc: cm...@cmake.org
> Subject: Re: [CMake] How to set _default_ timeout for the ctest command?
> 
> On 2015-12-09 09:23+0100 Marcel Loose wrote:
> 
>> Hi Alan,
>> Just by experimenting, I discovered that you also need to set
>> DART_TESTING_TIMEOUT. I'm not sure what the relationship (if any) is
>> between CTEST_TEST_TIMEOUT and DART_TESTING_TIMEOUT. I set them both in
>> the file CTestConfig.cmake. I get the feeling that DART_TESTING_TIMEOUT
>> is there for less than historic reasons. Maybe someone from Kitware can
>> shed a light on this.
> 
> Thanks, Marcel, for trying those experiments.
> 
> I tried some additional experiments and found that all that is needed is
> to set the CTEST_TEST_TIMEOUT value before CTest is included in my
> top-level CMakeLists.txt file.  (My previous experiment set that value
> after the include, but before the first add_test command.) Note that
> I do not use CTestConfig.cmake at all.
> 
> So the current experimental logic is
> # Control the default timeout for all ctests.
> set(CTEST_TEST_TIMEOUT 1)
> include(CTest)
> 
> Those commands generate the following timeout results in the build tree.
> 
> software@raven> find . -type f |xargs grep -i timeout
> ./CMakeCache.txt:DART_TESTING_TIMEOUT:STRING=1
> ./CMakeCache.txt://ADVANCED property for variable: DART_TESTING_TIMEOUT
> ./CMakeCache.txt:DART_TESTING_TIMEOUT-ADVANCED:INTERNAL=1
> ./DartConfiguration.tcl:# TimeOut is the amount of time in seconds to wait 
> for processes
> ./DartConfiguration.tcl:# to complete during testing.  After TimeOut seconds, 
> the
> ./DartConfiguration.tcl:TimeOut: 1
> ./DartConfiguration.tcl:# For CTest submissions that timeout, these options
> 
> So for this case, DART_TESTING_TIMEOUT is automatically set to the
> specified CTEST_TEST_TIMEOUT value.  (If CTEST_TEST_TIMEOUT is not set,
> the cached value of DART_TESTING_TIMEOUT is 1500, and the value of the
> timeout in DartConfiguration.tcl is also set to 1500).
> 
> Afterwards, ctest timed out at 1 second for all tests that exceeded
> that value, but it turns out that is a hard-coded value which cannot
> be superseded by the ctest --timeout option.  So this approach is not
> really ideal for the lapack developers who will want to increase the
> default limit by only an order of magnitude or less to substantially
> reduce the probability someone with a slow computer or special
> circumstances will have to override using the ctest --timeout option,
> but that change likely will not reduce that probability to zero so
> keeping the ability to override the lapack timeout default by the
> ctest --timeout option is still likely imporatant to them.
> 
> @CMake developers:
> 
> The documentation of CTEST_TEST_TIMEOUT (and DART_TESTING_TIMEOUT)
> includes the following language:
> 
> "The default timeout for each test if
> not specified by the `TIMEOUT` test property.
> 
> Also, the documentation of the ctest --timeout option says:
> 
> `--timeout `
> Set a global timeout on all tests.
> 
> This option will set a global timeout 

Re: [cmake-developers] Proposal to teach cmDepends to only take dependencies from the source tree

[Attila Krasznahorkay]

Dear All,

I was hoping to get some feedback from the developers on which direction to 
take this in. As I wrote before, I'm happy to help. But I don't want to spend 
time on an implementation that people will not accept in the end. I'd like us 
to first agree on how the code should behave after the addition of this new 
feature.

Cheers,
  Attila

> On 09 Dec 2015, at 15:38, Ben Boeckel <ben.boec...@kitware.com> wrote:
> 
> On Wed, Dec 09, 2015 at 09:19:45 +0100, Attila Krasznahorkay wrote:
>> I myself am on the side of simplicity. Using regular expressions would
>> allow us to do what I want. But if >95% of the people using this new
>> possibility would use it exactly like I plan to, then implementing it
>> in a more complicated way than necessary would just be a bad design
>> choice.
> 
> Do you have performance numbers for the change in your build between
> using include_directories (or target_include_directories), with and
> without SYSTEM, each with and without this change?
> 
> --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] Parallel jobs failed for cmake

[Attila Krasznahorkay]

Hi Igor,

At this point it's really not a CMake question, but a GNU Make one... The 
answer is actually right there in the first warning that you got.

make[4]: warning: jobserver unavailable: using -j1.  Add `+' to parent make 
rule.

I have to admit that I'm not absolutely sure about all the subtleties of this, 
but I defined my own build rules in the past that call make themselves, like:

core::
+(cd core; make)

With this, GNU Make is able to distribute the jobs between the subdirectories. 
(I have a number of such targets in my main Makefile.)

Cheers,
  Attila

> On 14 Dec 2015, at 07:34, Igor Sobinov  wrote:
> 
> Hello Bill,
> 
> Thanks, that's clear.
> 
> So, If I write in makefile
> 
> 
> build_release: $(RELEASE_DIR)
> @cd $(RELEASE_DIR); $(MAKE) release
> 
> I got an error
> 
> Also if I write
> 
> build_release: $(RELEASE_DIR)
> $(MAKE) release -C  $(RELEASE_DIR)
> 
> I got an error too
> 
> But this is successfull command:
> # cd $RELEASE_DIR; make release -j10
> 
> Why make doesn't support jobs for subdirs?
> 
> 
> Пятница, 11 декабря 2015, 14:14 -05:00 от Bill Hoffman 
> :
> 
> On 12/11/2015 7:24 AM, Igor Sobinov wrote:
> > Hello Bill,
> >
> > yes, make release is a custom command but that's not important.
> > I do the following:
> > # cd /home/igor/build_root/release_target
> > # make release -j5
> Yes, it is important, it is the reason it is not working. The custom 
> command needs to use $(MAKE) and not make to call make or you will get 
> this error. Child make calls need environment variables to get parallel 
> builds to work. The MAKE env var is used to pass them around.
> 
> -Bill
> 
> 
> 
> Bye, Igor
> 
> -- 
> 
> 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] what options

[Attila Krasznahorkay]

Hi,

Just to clarify: CMAKE_INSTALL_PREFIX is the variable that sets where the 
project will be installed. CMAKE_PREFIX_PATH is used (amongst other things) to 
find external projects during the configuration.

Cheers,
 Attila

> On 13 Dec 2015, at 21:20, Owen Hogarth II  wrote:
> 
> wow, that's excellent cmake -LAH lead me to the variable that I was looking 
> for.
> 
> Thank you very much Roger!
> 
> On Mon, Dec 14, 2015 at 3:56 AM, Roger Leigh  wrote:
> On 13/12/2015 19:44, Owen Hogarth II wrote:
> If you have a cmake project, what's the way to see what type of
> configuration options are available?
> 
> For example I know that I can pass -DCMAKE_PREFIX_PATH the set where the
> project will be installed.
> 
> Sometimes project creators add other things, such as building static or
> share libraries, SSE, NEON or other flags like those.
> 
> Is there a way to have cmake show all of those that the current project
> has exposed?
> 
> cmake -L[A][H] .
> 
> Lists the cache variables to set, optionally including advanced options and 
> help text.
> 
> See "List non-advanced cached variables" in 
> https://cmake.org/cmake/help/v3.4/manual/cmake.1.html
> 
> These are also shown with cmake-gui, which lists them in the user interface.
> 
> 
> Regards,
> Roger
> -- 
> 
> 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

-- 

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] Figuring out in a generator expression whether a name is a target

[Attila Krasznahorkay]

Dear All,

I'm trying to do something a bit more complicated, so please bear with me...

In our project we use a special kind of source code generator. Called a 
"dictionary generator". (https://root.cern.ch/how/how-use-reflex) To simplify 
the life of our users a bit, we provide a helper function for generating 
"dictionary libraries", which has a signature like:

atlas_add_dictionary( MyDictLibrary
  MyDictLibrary/MyDictLibraryDict.h
  MyDictLibrary/selection.xml
  INCLUDE_DIRS ...
  LINK_LIBRARIES ... )

Now, in order to make sure that the dictionary generation command succeeds, we 
need to pull in the public include paths of all the libraries that this library 
is supposed to be linked against, recursively. To do this, I do the following 
behind the scenes:

foreach( l ${ARG_LINK_LIBRARIES} )
   # Skip physical libraries:
   if( EXISTS ${l} )
  continue()
   endif()
   # Skip generator expressions:
   if( ${l} MATCHES "[$]<" )
  continue()
   endif()
   # Get the include directories of this library:
   list( APPEND includes 
"$" )
endforeach()

As long as the users only specify either library targets, or absolute library 
path names here, this works well. But I just ran into some issues where this 
function is called with a system library name like "rt". So the project 
generation bails, complaining that "rt" is not a target.

Would it be possible to figure out in a generator expression if a given name is 
a target or not? Clearly I can't make this decision in an

if( TARGET ${l} )

statement, as the target may only get defined after this function call.

For now I'll be able to work around this issue, but I wonder if it would be 
possible to provide a full-proof implementation that would not be killed by the 
users specifying a low-level system library like this in the future.

Cheers,
   Attila
-- 

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] Figuring out in a generator expression whether a name is a target

[Attila Krasznahorkay]

Hi,

Just to let people know how I solved it in the end...

After wondering for a little while, I realised that the following should 
actually work more robustly:

   # Get the interface directories of the linked libraries:
   if( ARG_LINK_LIBRARIES )
  # First declare an interface library that will help us collect the
  # include paths from them:
  set( _genLibName ${dictname}GeneratorLib )
  add_library( ${_genLibName} INTERFACE )
  target_link_libraries( ${_genLibName} INTERFACE ${ARG_LINK_LIBRARIES} )
  # Now use this interface library to get the include paths:
  list( APPEND incdirs
 "$<TARGET_PROPERTY:${_genLibName},INTERFACE_INCLUDE_DIRECTORIES>" )
  unset( _genLibName )
   endif()

In this case it becomes non-important what sort of libraries are given as the 
LINK_LIBRARIES argument. The intermediate interface library takes care of 
collecting the include directories from the entities that provide such a thing.

Cheers,
Attila

> On 11 Dec 2015, at 12:58, Attila Krasznahorkay 
> <attila.krasznahor...@gmail.com> wrote:
> 
> Dear All,
> 
> I'm trying to do something a bit more complicated, so please bear with me...
> 
> In our project we use a special kind of source code generator. Called a 
> "dictionary generator". (https://root.cern.ch/how/how-use-reflex) To simplify 
> the life of our users a bit, we provide a helper function for generating 
> "dictionary libraries", which has a signature like:
> 
> atlas_add_dictionary( MyDictLibrary
>  MyDictLibrary/MyDictLibraryDict.h
>  MyDictLibrary/selection.xml
>  INCLUDE_DIRS ...
>  LINK_LIBRARIES ... )
> 
> Now, in order to make sure that the dictionary generation command succeeds, 
> we need to pull in the public include paths of all the libraries that this 
> library is supposed to be linked against, recursively. To do this, I do the 
> following behind the scenes:
> 
> foreach( l ${ARG_LINK_LIBRARIES} )
>   # Skip physical libraries:
>   if( EXISTS ${l} )
>  continue()
>   endif()
>   # Skip generator expressions:
>   if( ${l} MATCHES "[$]<" )
>  continue()
>   endif()
>   # Get the include directories of this library:
>   list( APPEND includes 
> "$<TARGET_PROPERTY:${l}:INTERFACE_INCLUDE_DIRECTORIES>" )
> endforeach()
> 
> As long as the users only specify either library targets, or absolute library 
> path names here, this works well. But I just ran into some issues where this 
> function is called with a system library name like "rt". So the project 
> generation bails, complaining that "rt" is not a target.
> 
> Would it be possible to figure out in a generator expression if a given name 
> is a target or not? Clearly I can't make this decision in an
> 
> if( TARGET ${l} )
> 
> statement, as the target may only get defined after this function call.
> 
> For now I'll be able to work around this issue, but I wonder if it would be 
> possible to provide a full-proof implementation that would not be killed by 
> the users specifying a low-level system library like this in the future.
> 
> Cheers,
>   Attila

-- 

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] CPack and PackageMaker

[Attila Krasznahorkay]

Hi Robert,

I'm afraid that the sad situation is that nobody has done this yet, or is 
working on it at the moment.

I'm absolutely sure that if you can help with this by any amount, that will be 
most welcome by the CMake developers. It will certainly be most welcome by me, 
as I've been disappointed by the lack of this support as well. (But 
unfortunately can't spare the time to help out in writing this CPack generator.)

Cheers,
 Attila

> On 11 Dec 2015, at 17:44, Robert Bielik  wrote:
> 
> Really ? No one ? :)
> 
> So it's ok to go ahead and start create a new one ? ;)
> 
> Rgds,
> /R
> 
> Den 2015-12-09 kl. 16:56, skrev Robert Bielik:
>> Mac OSX:
>> 
>> Since PackageMaker has been deprecated by Apple, the new tools to use are 
>> pkgbuild [1] and productbuild [2].
>> 
>> Simple question: Is there any work being done by the CMake community on a 
>> new OS X CPack backend to support the above tools ?
>> 
>> Regards
>> /Robert
>> [1] 
>> https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/pkgbuild.1.html
>> [2] 
>> https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/productbuild.1.html
>> 
> 
> -- 
> 
> 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] How to set environment variables with spaces in commands

[Attila Krasznahorkay]

Hi Ruslan,

Thanks, this is good to know.

I absolutely agree that one needs to avoid using "&&" in the commands 
themselves. As it also causes problems when you try to use 
CTEST_USE_LAUNCHERS=1. (I myself ran into that issue...)

But I did not have any issues so far with putting "whatever" into a shell 
script that I then later execute. This is how I got around not being able to 
use wildcards in some installation commands for instance.

However, I quite like your solution of using a CMake script instead of a *nix 
shell one. As that should be indeed much more portable. Even if my current 
project will not work on Windows for a lot of reasons anyway...

Cheers,
  Attila

> On 10 Dec 2015, at 13:38, Ruslan Baratov <ruslan_bara...@yahoo.com> wrote:
> 
> On 10-Dec-15 12:52, Attila Krasznahorkay wrote:
>> Hi QP,
>> 
>> Probably not the intended solution, but what I’m doing in such cases is that 
>> in a patch step I create a shell script that does the configuration for me. 
>> With all the environment settings and everything. Like:
>> 
>> PATCH_COMMAND ${CMAKE_COMMAND} -E echo “cd someDir/; CC=\”something\” 
>> ./configure” > configure.sh
>> CONFIGURE_COMMAND sh configure.sh
>> 
> ...
> 
>> Unfortunately this makes the code quite unportable, as it will only work on 
>> POSIX platforms like this.
> Even on *nix platforms such code will not always works as expected. As 
> documentation states 
> (https://cmake.org/cmake/help/v3.4/module/ExternalProject.html):
> Behavior of shell operators like && is not defined.
> I've hit this on practice by using `LOG_* 1` feature. You can try this 
> example (I've moved PATCH_COMMAND to CONFIGURE_COMMAND since there is no 
> LOG_PATCH option):
> 
> https://gist.github.com/ruslo/e8c7be03521f167ae8f0
> 
> Result:
> [ 62%] Performing configure step for 'Foo'
> cd /.../Foo-prefix/src/Foo-build && /.../cmake -P 
> /.../Foo-prefix/src/Foo-stamp/Foo-configure-.cmake
> CMake Error at /.../Foo-prefix/src/Foo-stamp/Foo-configure-.cmake:16 
> (message):
>   Command failed: 1
> The reason of the failure is because CMake collect all arguments into one 
> command and run execute_process:
> set(command "/.../cmake;-E;echo;cd ..;>;configure.sh")
> execute_process(COMMAND ${command} RESULT_VARIABLE result)
> which of course doesn't make sense.
> 
> This makes writing ExternalProject_Add steps with modification of environment 
> quite non-trivial task (at least doing it correctly). This feature definitely 
> missing in CMake. I've mentioned it once already: 
> https://cmake.org/pipermail/cmake-developers/2015-August/026053.html
> 
> but I've changed my mind about the approach because of LOG_* issue. Now I do 
> the next:
> 
> * wrap each step with CMake script, i.e. instead of `CC=something 
> ./configure` do
> set(ENV{CC} "something")
> execute_process(COMMAND ./configure ...)
> * run CMake script in *_COMMAND:
> 
> CONFIGURE_COMMAND
> "${CMAKE_COMMAND}" -P "/path/to/configure.cmake"
> This makes it cross-platform and *_LOG friendly but require more tricks. Like 
> if you're building in source (non-cmake packages) you have to copy script 
> before execution since CMake will remove source directory on DOWNLOAD step. 
> Which makes it looks like this:
> 
> CONFIGURE_COMMAND
> "${CMAKE_COMMAND}" -E copy "/path/to/source/configure.cmake" 
> "/path/to/unpacked/configure.cmake"
> COMMAND
> "${CMAKE_COMMAND}" -P "/path/to/unpacked/configure.cmake"
> 
> PS I'm hitting problems in ExternalProject with environment variables all the 
> time. E.g. at this moment fixing MinGW + Boost: 
> https://github.com/ruslo/hunter/pull/273
> 
> Ruslo
> 
>>  But I guess that’s the case anyway once you start setting environment 
>> variables.
>> 
>> Cheers,
>>Attila
>> 
>> P.S. I often create build.sh and install.sh scripts as well in additional 
>> patch commands.
>> 
>> 
>>> On Dec 10, 2015, at 5:35 AM, Qingping Hou <dave2008...@gmail.com>
>>>  wrote:
>>> 
>>> Hi all,
>>> 
>>> I am trying to setup an ExternalProject in cmake but got stuck in the
>>> configuration step. I am using ccache to speed up the compilation:
>>> 
>>> ```
>>> ExternalProject_Add(
>>>  ...
>>>  CONFIGURE_COMMAND CC="ccache arm-linux-gnueabihf-gcc" ./configure
>>>  ...
>>> )
>>> ```
>>> 
>>> However, when cmake generates the Makefile, it moves the quotes around
>>> and breaks the command:
&

Re: [CMake] How to set environment variables with spaces in commands

[Attila Krasznahorkay]

Hi QP,

Probably not the intended solution, but what I’m doing in such cases is that in 
a patch step I create a shell script that does the configuration for me. With 
all the environment settings and everything. Like:

PATCH_COMMAND ${CMAKE_COMMAND} -E echo “cd someDir/; CC=\”something\” 
./configure” > configure.sh
CONFIGURE_COMMAND sh configure.sh

Unfortunately this makes the code quite unportable, as it will only work on 
POSIX platforms like this. But I guess that’s the case anyway once you start 
setting environment variables.

Cheers,
   Attila

P.S. I often create build.sh and install.sh scripts as well in additional patch 
commands.

> On Dec 10, 2015, at 5:35 AM, Qingping Hou  wrote:
> 
> Hi all,
> 
> I am trying to setup an ExternalProject in cmake but got stuck in the
> configuration step. I am using ccache to speed up the compilation:
> 
> ```
> ExternalProject_Add(
>  ...
>  CONFIGURE_COMMAND CC="ccache arm-linux-gnueabihf-gcc" ./configure
>  ...
> )
> ```
> 
> However, when cmake generates the Makefile, it moves the quotes around
> and breaks the command:
> 
> ```
> "CC=ccache arm-linux-gnueabihf-gcc" ./configure
> ```
> 
> I have tried various escaping method to try to get it work properly
> without any luck. Is this a bug or an unintended feature?
> 
> Thanks,
> QP
> -- 
> 
> 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] organizing includes statements

[Attila Krasznahorkay]

Hi Owen,

This seems like a textbook example of using target_include_directories(…) with 
generator expressions. Let’s take the example where:

lib1/headers/lib1.h
lib1/lib1.c
lib2/headers/lib2.h
lib2/lib2.c

If you want to be able to include lib1.h and lib2.h with simply

#include “lib1.h”

and

#include “lib2.h”

in your user code, and in the library code itself, you’d do something like:

add_library( lib1 SHARED lib1/lib1.c )
target_include_directories( lib1 PUBLIC
   $
   $ )

add_library( lib2 SHARED lib2/lib2.c )
target_include_directories( lib2 PUBLIC
   $
   $ )
target_link_libraries( lib2 lib1 )

install( FILES lib1/headers/lib1.h lib2/headers/lib2.h DESTINATION include )
install( TARGETS lib1 lib2 DESTINATION lib )

In this setup “lib1” should get a -I${CMAKE_SOURCE_DIR}/lib1/headers flag, and 
“lib2” should get both -I${CMAKE_SOURCE_DIR}/lib1/headers and 
-I${CMAKE_SOURCE_DIR}/lib2/headers. Finally the headers both get installed into 
the same include directory, so an outside user will just have to be able to 
find that one directory. (Or if you export CMake’s targets, the lib1/2 imported 
targets will know that their header files are in that directory.)

Cheers,
Attila

> On Dec 10, 2015, at 12:07 AM, Owen Alanzo Hogarth  wrote:
> 
> hi
> 
> I am building a shared library project that's composed of many smaller shared 
> library files.
> 
> Here's the main shared library project and a list of all the sub projects.
> 
> SET(HEADER_FILES ${CMAKE_CURRENT_SOURCE_DIR}/headers/main_lib.h)
> SET(SRC_FILES ${CMAKE_CURRENT_SOURCE_DIR}/main_lib.c)
> SET(TARGET_LIBS core_math point2d line2d quad2d timer_utils)
> 
> ADD_LIBRARY(main_lib SHARED ${SRC_FILES} ${HEADER_FILES})
> TARGET_LINK_LIBRARIES(core_engine ${TARGET_LIBS})
> 
> i have each module setup like this.
> module
> module/headers/module.h
> module/module.c
> 
> then the module.c will look like this
> #include "headers/module.h"
> 
> the file main_lib.h depends on all those target libs, which makes my 
> main_lib.h file's include statement look like this
> 
> #include "../../module/headers/module.h"
> #include "../../module1/headers/module1.h"
> #include "../../module2/headers/module2.h"
> 
> 
> is there any way that I can clean up these includes?
> 
> For example if I want to use io functions I can just do #include  or 
> #include 
> 
> for math functions.
> 
> I would like to make my include statements not relative to the files actual 
> location, the way it's currently hard coded.
> -- 
> 
> 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

[cmake-developers] Proposal to teach cmDepends to only take dependencies from the source tree

[Attila Krasznahorkay]

Dear All,

In our software infrastructure I now got to the point that in building "high 
level" packages/projects the CMake build spends a very noticeable amount of 
time in calculating the dependencies of source files. To give you a feel of the 
issue, in one example that I was profiling, I build a small "package" that uses 
>180 other "packages", which at this point are all installed on a network file 
system (AFS). Those low level packages themselves depend on N external packages 
as well (like Boost, Oracle, etc.).

So the include list for the build becomes very long, with most of the needed 
headers being outside of the source tree. In this case evaluating all the 
dependencies for a shared library made up of just 3 source files can take >10 
seconds.

I tried to find a way to tell CMake to ignore the dependencies that are outside 
of the source tree. As at this point for my use case those files can be 
considered fixed. I don't need to consider that they may change without me 
knowing. But as far as I could see, there is no mechanism in the code at the 
moment to achieve this.

I did consider teaching cmDepends to only take non-system include paths into 
account for the dependency calculation. So that whatever is specified as a 
system include path, would be ignored. But since I found that GCC becomes 
significantly slower in building my sources if I specify >100 -isystem /afs/... 
paths to it compared to specifying all those paths with -I, I gave up on this 
idea.

I also considered adding a new regular expression to cmDependsC to be able to 
specify using a regular expression which include paths to take into account and 
which to ignore. Which could still be a good idea to implement in cmDepends 
(not cmDependsC) later on, but for my own use case something simpler was enough.

In the end I applied the following patch to CMake 3.4.1 locally to speed it up 
for my use case very significantly. Of course this is not a patch that could be 
applied to CMake for a general audience. But I do think that if this 
code/behaviour could be switched on using something like a directory property / 
global variable, a lot of users could make good use of it. As it can be a 
reasonable assumption in many development environments that only the changes 
inside of the source tree should be tracked by the build system.

If you think that this is a good idea, I would be willing to provide some help 
in implementing it "properly" as well.

Cheers,
 Attila



cmDepends-sourceOnly.diff
Description: Binary data
-- 

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] Control the build target's external dependencies

[Attila Krasznahorkay]

Just to answer myself: After looking at the source code, I now understand that 
the regular expression set by include_regular_expression(...) is not compared 
against the full path name of the included file, but just what's in the source 
file after #include. So this machinery is non too useful for me at the moment.

For now I patched CMake locally with the following to ignore all out of source 
files in the dependency generation for me. With:

diff -u -r orig/cmake-3.4.1/Source/cmDepends.cxx 
cmake-3.4.1/Source/cmDepends.cxx
--- orig/cmake-3.4.1/Source/cmDepends.cxx   2015-12-02 16:43:21.0 
+0100
+++ cmake-3.4.1/Source/cmDepends.cxx2015-12-07 13:59:07.039749715 +0100
@@ -18,6 +18,7 @@
 #include "cmFileTimeComparison.h"
 #include 
 #include 
+#include 
 
 //
 cmDepends::cmDepends(cmLocalGenerator* lg, const char* targetDir):
@@ -291,6 +292,13 @@
   return okay;
 }
 
+// Helper predicate for removing absolute paths from the include directory
+// list.
+bool IsAbsolutePath( const std::string& path )
+{
+  return cmSystemTools::FileIsFullPath( path );
+}
+
 //
 void cmDepends::SetIncludePathFromLanguage(const std::string& lang)
 {
@@ -317,4 +325,8 @@
   cmSystemTools::ExpandListArgument(includePath, this->IncludePath);
   }
 }
+  // Remove all absolute paths from the dependency evaluation:
+  auto itr = std::remove_if( this->IncludePath.begin(), 
this->IncludePath.end(),
+ IsAbsolutePath );
+  this->IncludePath.erase( itr, this->IncludePath.end() );
 }

(Could be implemented with slightly fewer lines as well.)

Which sped up the generation of these depend.make files immensely. So I wonder 
if turning on this behaviour could be a new thing in the future. As I imagine 
that it could be useful to a lot of people if it could be set via some property 
that only files from the source directory should be considered in the 
dependency calculation.

Should one open a bug report with this? (Does the CMake bug tracking system 
have the ability to track "feature requests"?)

Cheers,
   Attila

> On 07 Dec 2015, at 11:55, Attila Krasznahorkay 
> <attila.krasznahor...@gmail.com> wrote:
> 
> Dear All,
> 
> Maybe I should've google-d better. So now I started experimenting with 
> include_regular_expression(...).
> 
> https://cmake.org/cmake/help/v3.0/command/include_regular_expression.html
> 
> But now I'm having a problem with expressing my intent with a regular 
> expression. In principle I'd like to only take headers from the source 
> directory into account in the dependency calculation. So I first tried this:
> 
> include_regular_expression( "^${CMAKE_SOURCE_DIR}.*$" )
> 
> But this was way too restrictive. As headers from the source directory 
> normally show up with relative paths in the depend.make files.
> 
> So okay, I tried this next:
> 
> include_regular_expression( "^(${CMAKE_SOURCE_DIR}.*)|([^/]+.*)$" )
> 
> (To try to make it only accept paths that are either in CMAKE_SOURCE_DIR, or 
> are not starting with "/".)
> 
> But this didn't work either. I'm back to having all the boost files in my 
> dependency list.
> 
> Any suggestion for how I could express my intent in a regular expression that 
> CMake would understand?
> 
> Cheers,
> Attila
> 
>> On 07 Dec 2015, at 10:57, Attila Krasznahorkay 
>> <attila.krasznahor...@gmail.com> wrote:
>> 
>> Dear All,
>> 
>> I'm struggling since a few days with the following issue.
>> 
>> Our development setup is such that we build large software projects in a 
>> nightly build system, which puts these projects onto a network drive. The 
>> developers then set up these nightly projects, and build their own code 
>> against them. (They can even rebuild parts that are in the nightly itself, 
>> that also required some clever tricks in CMake...)
>> 
>> This kind of works by now. But the system is incredibly slow. When I try to 
>> build some source code against installed releases on the network file 
>> system, >90% of the time is seemingly just spent in dependency 
>> calculation/evaluation. To demonstrate the extent of the issue, here is an 
>> example of the files generated by CMake for one of our "packages". (Sorry, 
>> they are pretty large. But that's the point...) Mind you, this is a very 
>> simple package that just picks up Boost from the network disk. For high 
>> level packages the depend.make file can be up to 2 MB in size. :-(
>> 
>> 
>> 
>> As you can see, I tried to convince CMake to treat t

[CMake] Making CMake *not* use -isystem at all

[Attila Krasznahorkay]

Dear All,

I'm still debugging the performance problems of our build. But now I bumped 
into another surprising thing.

Our "highest level" packages can depend on a *lot* of low level packages. The 
one I'm testing now depends on more than 180 of them.

This generates >180 -isystem flags for the compilation lines. But I found a 
very surprising thing. If I replace all of these -isystem flags with -I ones by 
simply modifying the flags.cmake files that CMake generated for me, the build 
time of my code is cut to less than half of what it is when using -isystem.

So... How do I tell CMake to forget about using -isystem all together, and take 
all my include directories with -I?

Not using SYSTEM in target_include_directories and include_directories doesn't 
seem to make a difference. I still get all my out-of-source directories with 
-isystem. I even tried setting CMAKE_INCLUDE_SYSTEM_FLAG_CXX and 
CMAKE_INCLUDE_SYSTEM_FLAG_C to "-I " forcefully. But this didn't help either. 
Neither did explicitly unsetting these variables.

How could it be done then? How could I force CMake to always use -I for the 
directories that I give to either include_directories or 
target_include_directories?

Cheers,
  Attila
-- 

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] Control the build target's external dependencies

[Attila Krasznahorkay]

Dear All,

I'm struggling since a few days with the following issue.

Our development setup is such that we build large software projects in a 
nightly build system, which puts these projects onto a network drive. The 
developers then set up these nightly projects, and build their own code against 
them. (They can even rebuild parts that are in the nightly itself, that also 
required some clever tricks in CMake...)

This kind of works by now. But the system is incredibly slow. When I try to 
build some source code against installed releases on the network file system, 
>90% of the time is seemingly just spent in dependency calculation/evaluation. 
To demonstrate the extent of the issue, here is an example of the files 
generated by CMake for one of our "packages". (Sorry, they are pretty large. 
But that's the point...) Mind you, this is a very simple package that just 
picks up Boost from the network disk. For high level packages the depend.make 
file can be up to 2 MB in size. :-(



depend.make
Description: Binary data


flags.make
Description: Binary data


As you can see, I tried to convince CMake to treat the include directories 
coming from the network file system (AFS) as system include directories. But 
still, the dependencies put into depend.make list every single header file that 
the build targets have any relationship with.

As it turns out, AFS is pretty slow for such operations. Checking the change 
times of thousands of files. At least this is what I contribute the 
ridiculously slow build times to. (Not for this example. This package still 
builds reasonably. It's the higher level packages that break down completely. I 
just couldn't attach example files from those due to the size limitations of 
this mailing list.)

So... How could one convince CMake to exclude some directories from the 
dependency setup? The files that are part of the nightly builds should 
definitely not need to be checked for changes every time I run a build. As you 
can see, depend.make even list all the Boost headers at the moment. :-(

What I tried so far was to specify the include directories using SYSTEM in 
target_include_directories. But it didn't make any difference whether I used 
SYSTEM or not.

Is there some other mechanism that I could use here?

Cheers,
Attila-- 

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] Control the build target's external dependencies

[Attila Krasznahorkay]

Dear All,

Maybe I should've google-d better. So now I started experimenting with 
include_regular_expression(...).

https://cmake.org/cmake/help/v3.0/command/include_regular_expression.html

But now I'm having a problem with expressing my intent with a regular 
expression. In principle I'd like to only take headers from the source 
directory into account in the dependency calculation. So I first tried this:

include_regular_expression( "^${CMAKE_SOURCE_DIR}.*$" )

But this was way too restrictive. As headers from the source directory normally 
show up with relative paths in the depend.make files.

So okay, I tried this next:

include_regular_expression( "^(${CMAKE_SOURCE_DIR}.*)|([^/]+.*)$" )

(To try to make it only accept paths that are either in CMAKE_SOURCE_DIR, or 
are not starting with "/".)

But this didn't work either. I'm back to having all the boost files in my 
dependency list.

Any suggestion for how I could express my intent in a regular expression that 
CMake would understand?

Cheers,
 Attila

> On 07 Dec 2015, at 10:57, Attila Krasznahorkay 
> <attila.krasznahor...@gmail.com> wrote:
> 
> Dear All,
> 
> I'm struggling since a few days with the following issue.
> 
> Our development setup is such that we build large software projects in a 
> nightly build system, which puts these projects onto a network drive. The 
> developers then set up these nightly projects, and build their own code 
> against them. (They can even rebuild parts that are in the nightly itself, 
> that also required some clever tricks in CMake...)
> 
> This kind of works by now. But the system is incredibly slow. When I try to 
> build some source code against installed releases on the network file system, 
> >90% of the time is seemingly just spent in dependency 
> calculation/evaluation. To demonstrate the extent of the issue, here is an 
> example of the files generated by CMake for one of our "packages". (Sorry, 
> they are pretty large. But that's the point...) Mind you, this is a very 
> simple package that just picks up Boost from the network disk. For high level 
> packages the depend.make file can be up to 2 MB in size. :-(
> 
> 
> 
> As you can see, I tried to convince CMake to treat the include directories 
> coming from the network file system (AFS) as system include directories. But 
> still, the dependencies put into depend.make list every single header file 
> that the build targets have any relationship with.
> 
> As it turns out, AFS is pretty slow for such operations. Checking the change 
> times of thousands of files. At least this is what I contribute the 
> ridiculously slow build times to. (Not for this example. This package still 
> builds reasonably. It's the higher level packages that break down completely. 
> I just couldn't attach example files from those due to the size limitations 
> of this mailing list.)
> 
> So... How could one convince CMake to exclude some directories from the 
> dependency setup? The files that are part of the nightly builds should 
> definitely not need to be checked for changes every time I run a build. As 
> you can see, depend.make even list all the Boost headers at the moment. :-(
> 
> What I tried so far was to specify the include directories using SYSTEM in 
> target_include_directories. But it didn't make any difference whether I used 
> SYSTEM or not.
> 
> Is there some other mechanism that I could use here?
> 
> Cheers,
>Attila

-- 

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] Making CMake *not* use -isystem at all

[Attila Krasznahorkay]

Hi Alex,

From what I could see, if the base CMake code decides that internally 
CMAKE_INCLUDE_SYSTEM_FLAG_CXX needs to be set to “-isystem “, then I can’t 
influence this decision from the outside.

But the reason that the decision between using -I and -isystem seemed so 
inexplainable to me was that my project uses imported targets quite heavily. 
And as I had to learn, CMake treats the include directories set on imported 
libraries as system includes by default. Regardless whether those were set as 
system includes originally or not. After some google-ing I found out about it 
here:

https://cmake.org/cmake/help/v3.0/prop_tgt/NO_SYSTEM_FROM_IMPORTED.html

After setting CMAKE_NO_SYSTEM_FROM_IMPORTED to TRUE, my project now uses -I and 
-isystem includes as I originally expected it to.

And it could still be interesting to people that apparently using -isystem for 
directories on network disks is not a good idea. I’m really not sure what GCC 
does in the background exactly, but it clearly has some noticeable overhead 
over using -I for the same directories. So for now I just stopped using system 
include directories myself completely.

Cheers,
Attila

> On Dec 7, 2015, at 10:05 PM, Alexander Neundorf <a.neundorf-w...@gmx.net> 
> wrote:
> 
> On Monday, December 07, 2015 15:39:40 Attila Krasznahorkay wrote:
> > Dear All,
> > 
> > I'm still debugging the performance problems of our build. But now I bumped
> > into another surprising thing.
> > 
> > Our "highest level" packages can depend on a *lot* of low level packages.
> > The one I'm testing now depends on more than 180 of them.
> > 
> > This generates >180 -isystem flags for the compilation lines. But I found a
> > very surprising thing. If I replace all of these -isystem flags with -I
> > ones by simply modifying the flags.cmake files that CMake generated for me,
> > the build time of my code is cut to less than half of what it is when using
> > -isystem.
> > 
> > So... How do I tell CMake to forget about using -isystem all together, and
> > take all my include directories with -I?
> > 
> > Not using SYSTEM in target_include_directories and include_directories
> > doesn't seem to make a difference. I still get all my out-of-source
> > directories with -isystem. I even tried setting
> > CMAKE_INCLUDE_SYSTEM_FLAG_CXX and CMAKE_INCLUDE_SYSTEM_FLAG_C to "-I "
> > forcefully. But this didn't help either. Neither did explicitly unsetting
> > these variables.
>  
> I would have expected this to work.
> Maybe set them to -I on the initial cmake run ?
>  
> 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

[CMake] Adding required source files to a custom target

[Attila Krasznahorkay]

Dear All,

Is it possible to add additional source files to an already existing custom 
target?

My project needs to generate a number of "different things", which it does by 
setting up many custom commands. In order to trigger the generation of 
everything, I currently need to set up an inconvenient number of custom targets 
as well. Would it be possible to attach multiple custom commands to an already 
existing custom target?

Unfortunately it's not really an option to only set up the custom target once 
all the custom commands are already configured, and all their outputs are 
already known.

I guess my question is, what property of a custom target I need to append file 
names to? What internal property gets set with the values passed to the SOURCES 
argument of add_custom_target? (That I could then append additional file names 
to.)

Cheers,
   Attila
-- 

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] Adding required source files to a custom target

[Attila Krasznahorkay]

Hi Nils,

Clever. I didn't even consider specifying the SOURCES argument of the custom 
target with a generator expression. But it seems to work perfectly.

Thanks!
 Attila

> On 03 Dec 2015, at 16:00, Nils Gladitz <nilsglad...@gmail.com> wrote:
> 
> On 12/03/2015 03:47 PM, Attila Krasznahorkay wrote:
>> Dear All,
>> 
>> Is it possible to add additional source files to an already existing custom 
>> target?
>> 
>> My project needs to generate a number of "different things", which it does 
>> by setting up many custom commands. In order to trigger the generation of 
>> everything, I currently need to set up an inconvenient number of custom 
>> targets as well. Would it be possible to attach multiple custom commands to 
>> an already existing custom target?
>> 
> 
> e.g. this nonsense example seems to work:
> 
> cmake_minimum_required(VERSION 3.4)
> 
> add_custom_target(foo ALL
> COMMAND ${CMAKE_COMMAND} -E echo $<TARGET_PROPERTY:foo,MY_INPUTS>
> DEPENDS "$<TARGET_PROPERTY:foo,MY_INPUTS>"
> VERBATIM
> )
> 
> function(add_custom_input input)
> set(_output "${CMAKE_CURRENT_BINARY_DIR}/${input}.out")
> set(_input "${CMAKE_CURRENT_SOURCE_DIR}/${input}")
> 
> add_custom_command(OUTPUT ${_output}
> COMMAND ${CMAKE_COMMAND} -E copy ${_input} ${_output}
> DEPENDS ${_input}
> VERBATIM
> )
> 
> set_property(TARGET foo APPEND PROPERTY MY_INPUTS ${_output})
> endfunction()
> 
> file(WRITE input1)
> add_custom_input(input1)
> 
> file(WRITE input2)
> add_custom_input(input2)
> 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

Re: [CMake] generator expression for set_target_properties

[Attila Krasznahorkay]

Hi Lloyd,

You mean like:

if( ${CMAKE_BUILD_TYPE} STREQUAL "Release" )
   set_target_properties( myexec PROPERTIES WIN32_EXECUTABLE TRUE )
endif()

?

Or would you like the build configuration to change in this respect when you 
change the build type in the IDE? This latter may not be possible to do. But 
others may very well correct me.

Cheers,
Attila

> On 03 Dec 2015, at 07:32, Lloyd  wrote:
> 
> Hi,
> 
> We have a cmake file for Qt project. We want to hide the console from release 
> build. For that we are using
> 
> ADD_EXECUTABLE(myexec ${MYEXEC_SRC} )
> SET_TARGET_PROPERTIES(myexec PROPERTIES WIN32_EXECUTABLE true) 
> 
> Is it possible for me to set this property only for the release build?
> 
> I am using cmake 2.8, Windows 7, VS 2013
> 
> Thanks,
>   Lloyd
> -- 
> 
> 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

[CMake] Custom command concurrency

[Attila Krasznahorkay]

Dear All,

I'm running into a new issue with my custom commands. :-(

I have a project with many subdirectories. Where most subdirectories generate 
some files during the build. Some of which need to be merged into a single file 
at the end of the build.

In my current implementation the subdirectories declare both a custom command 
and a custom target for generating these files. So that the merge command in 
the main directory could depend on the custom targets of the subdirectories. 
(As the merge command can't depend on the generated files themselves directly.)

Now, the merge command is not the only use using these generated files. They 
are also used inside the subdirectories in order to build some libraries. And 
now the problem comes. Apparently CMake / GNU Make doesn't make sure that the 
generation command would only run once. Attached is a simple example. When 
running make in single-process mode, things happen as I would expect them to.

Scanning dependencies of target SubdirTarget
[ 33%] Generating partialFile.txt
[ 33%] Built target SubdirTarget
Scanning dependencies of target MergeTarget
[ 66%] Generating merged.txt
[ 66%] Built target MergeTarget
Scanning dependencies of target CompileSubdirTarget
[100%] Built target CompileSubdirTarget

But when I use multiple build processes, I get:

Scanning dependencies of target SubdirTarget
Scanning dependencies of target CompileSubdirTarget
[ 66%] Generating partialFile.txt
[ 66%] Generating partialFile.txt
[ 66%] Built target CompileSubdirTarget
[ 66%] Built target SubdirTarget
Scanning dependencies of target MergeTarget
[100%] Generating merged.txt
[100%] Built target MergeTarget

So, the file generation gets triggered twice at the same time. Of course in 
this simple example this wouldn't matter. But the generator that I use in real 
life can't handle this. As it creates some temporary files as it runs, which 
interfere with each other. So I come out with a corrupt output file.

Does anyone have any suggestions? I would really need to be able to make sure 
that this custom command would not be executed multiple times. And most of all, 
not multiple times at once.

Cheers,
Attila

P.S. It seems that the Ninja generator is a bit better in this respect. But of 
course it's not an option to not have my project work correctly with the 
Makefile generator.



custom_command_concurrency.tar.bz2
Description: BZip2 compressed data
-- 

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] Imported ExternalProject Libraries with Ninja

[Attila Krasznahorkay]

Hi Zac,

In recent versions of CMake (not sure when it was introduced, but it's 
available in 3.2.X) you have an extra argument for ExternalProject_Add: 
BUILD_BYPRODUCTS.

https://cmake.org/cmake/help/v3.2/module/ExternalProject.html

I use this in a setup very similar to yours to declare all the shared libraries 
that my external project target will make. This way Ninja knows where to expect 
those files from.

Cheers,
 Attila

> On 20 Nov 2015, at 19:02, Zac Bergquist  wrote:
> 
> Hello,
> 
> I'm using ExternalProject to build libxml2 into a static library, which I 
> link my application to.  I've read a few warnings about combining 
> ExternalProject with standard CMake targets, but I'm pretty sure this is the 
> approach I want to take.  I do not want to install libxml2 globally because 
> I'm configuring it with a very specific set of options.
> 
> I have something like this:
> 
> # build libxml2
> ExternalProject_Add(libxml2
>BINARY_DIR ${CMAKE_CURRENT_BINARY_DIR}/libxml2-2.9.1
>CONFIGURE_COMMAND ${XML_SRC}/configure ${CONFIGURE_FLAGS}
>...
> )
> 
> # tell CMake that the ExternalProject generated a library
> add_library(xml2 STATIC IMPORTED GLOBAL)
> set_property(TARGET xml2 PROPERTY
> IMPORTED_LOCATION 
> ${CMAKE_CURRENT_BINARY_DIR}/libxml2-2.9.1/.libs/libxml2.a
> )
> 
> add_executable(foo ${SOURCES})
> 
> add_dependency(foo libxml2)
> 
> target_link_libraries(foo xml2)
> 
> I realize that this isn't as portable as it could [should] be because I'm 
> including information about where the build files will be generated, but I'm 
> okay with this.
> 
> With the standard Unix makefile generator, everything works fine.  I can run 
> `make foo` and it configures and builds libxml2, then builds foo and links to 
> the static library.
> 
> However, with the ninja generator, I get an error:
> 
> ninja: error: "libxml2-2.9.1/.libs/libxml2.a', needed by 'out/bin/foo', 
> missing and no known rule to make it
> 
> For some reason the Ninja build is not picking up on the fact that libxml2.a 
> is generated by the external project.  The only way I'm able to get this to 
> build is to run `ninja xml2` followed by `ninja foo`.
> 
> Am I doing something wrong or could this be a bug in CMake?  If so, are there 
> any workarounds.  I just started using Ninja and am really enjoying the speed 
> advantage over make.
> 
> Thanks,
> Zac
> -- 
> 
> 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] How to depend on files generated in a subdirectory?

[Attila Krasznahorkay]

Hi Zac,

Interesting. I was convinced that it wouldn't work with Ninja. But it does.

Thanks!
 Attila

> On 19 Nov 2015, at 00:23, Zac Bergquist <zbergquis...@gmail.com> wrote:
> 
> Would this work?
> 
> add_dependencies(MergeFiles SubdirTarget)
> 
> On Nov 18, 2015 12:56 PM, "Attila Krasznahorkay" 
> <attila.krasznahor...@gmail.com> wrote:
> Dear All,
> 
> I'm trying to do something that may be very easy to implement, but I'm really 
> struggling with it at the moment...
> 
> I have a project in which I generate various files in subdirectories. Which I 
> add to the main project file using add_subdirectory(...). Some of these files 
> I need to merge into a single file at the end of the build. For which I tried 
> to set up a custom command in my main project file. But I can't convince this 
> main project file to find out how to generate the files whose generation rule 
> sits in a subdirectory.
> 
> Attached is a simple example of what I mean. In this example it is possible 
> to execute the following commands successfully:
> 
> make SubdirTarget
> make
> 
> Since by the time the main target is built, its source files are already 
> available. But if I try to just execute "make" first, I get:
> 
> Scanning dependencies of target MergeFiles
> make[2]: *** No rule to make target `subdir/file3.txt', needed by 
> `merged.txt'.  Stop.
> make[1]: *** [CMakeFiles/MergeFiles.dir/all] Error 2
> make: *** [all] Error 2
> 
> I tried a number of different directory/file name combinations by now, but 
> the problematic thing in the end seems to be that these files are generated 
> in a different directory than where I try to use them.
> 
> Do you have a suggestion on how I could do something like this?
> 
> Cheers,
> Attila
> 
> 
> --
> 
> 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

[CMake] How to depend on files generated in a subdirectory?

[Attila Krasznahorkay]

Dear All,

I'm trying to do something that may be very easy to implement, but I'm really 
struggling with it at the moment...

I have a project in which I generate various files in subdirectories. Which I 
add to the main project file using add_subdirectory(...). Some of these files I 
need to merge into a single file at the end of the build. For which I tried to 
set up a custom command in my main project file. But I can't convince this main 
project file to find out how to generate the files whose generation rule sits 
in a subdirectory.

Attached is a simple example of what I mean. In this example it is possible to 
execute the following commands successfully:

make SubdirTarget
make

Since by the time the main target is built, its source files are already 
available. But if I try to just execute "make" first, I get:

Scanning dependencies of target MergeFiles
make[2]: *** No rule to make target `subdir/file3.txt', needed by `merged.txt'. 
 Stop.
make[1]: *** [CMakeFiles/MergeFiles.dir/all] Error 2
make: *** [all] Error 2

I tried a number of different directory/file name combinations by now, but the 
problematic thing in the end seems to be that these files are generated in a 
different directory than where I try to use them.

Do you have a suggestion on how I could do something like this?

Cheers,
Attila



mergeGeneratedExample.tar.bz2
Description: BZip2 compressed data
-- 

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] Custom message if target fails

[Attila Krasznahorkay]

Hi Daniel,

You could even do it in a *much* more general way.

We write custom log files about our builds by providing a "replacement" for the 
ctest executable. So that when we configure the build with

-DCTEST_USE_LAUNCHERS

, our script would catch *all* the build commands. (To have a chance to put the 
commands and their results into various log files. We forward the actual build 
command execution to the "normal" ctest executable.) You could use such a 
script to print a custom failure message.

Cheers,
   Attila

> On 12 Nov 2015, at 09:43, Daniel Schepler  
> wrote:
> 
> I'm assuming this is under a Unix platform - in my experience, on Windows, I 
> get the color escape codes even running cmake builds under Jenkins.  On Unix 
> platforms, you could install expect and use the unbuffer tool, e.g. "unbuffer 
> make -j8 -k".
> -- 
> Daniel Schepler
> 
> From: CMake [cmake-boun...@cmake.org] on behalf of Daniel Wirtz 
> [daniel.wi...@simtech.uni-stuttgart.de]
> Sent: Thursday, November 12, 2015 2:05 AM
> To: cmake@cmake.org
> Subject: Re: [CMake] Custom message if target fails
> 
> Hey,
> 
> neat idea, i've tried and it works (i have custom targets there).
> However, the "nice" colored build text output of such a solution gets
> lost completely (pipes etc); are there any alternative ideas/solutions?
> 
> thanks again!
> 
> Dr. Daniel Wirtz
> Dipl. Math. Dipl. Inf.
> SRC SimTech
> Pfaffenwaldring 5a
> +49 711 685 60044
> 
> On 11/12/2015 10:10 AM, Nils Gladitz wrote:
>> On 11/12/2015 09:54 AM, Daniel Wirtz wrote:
>>> Dear all,
>>> 
>>> i've been thinking on this for a while but i can't seem to get my
>>> head around how to solve this.
>>> The task is simple: How can i display a custom error message if a
>>> target fails to build for whatever reason?
>>> - cmake ..
>>> - make
>>> - 
>>> - below the (compile-tool dependent error output) i'd like to print
>>> something like "Whoops it went wrong, type this and that or visit
>>> this or that website for help"
>>> 
>> 
>> There is no generic build system feature for this.
>> 
>> You haven't provided any details on what kind of target this concerns
>> or what is to be diagnosed specifically but ...
>> 
>> Assuming this is a custom target / custom command you could replace
>> the actual command with a wrapper (e.g. cmake -P script) that:
>>- runs the actual command (e.g. execute_process())
>>- outputs a message based on the actual command's exit status
>> (e.g. message("This and that"))
>>- exits with (roughly) the same exit status as the actual command
>> (e.g. message(FATAL_ERROR) on failure))
>> 
>> For regular build targets (executables, libraries) there is nothing to
>> be done at build time.
>> Depending on what it is you are actually diagnosing you might want to
>> try to diagnose it during configuration rather than during the build.
>> 
>> 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
> 
> -- 
> 
> 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] The project files that CMake generates can't be moved

[Attila Krasznahorkay]

Hi,

I'm a bit surprised about this answer.

Sure, build areas are not to be moved around. I completely agree. But this is 
why we have the concept of installing releases. As long as you configure your 
build correctly, you should be able to move around your install directory. As 
the binaries by default will not have absolute paths in them after 
installation. At least not to "themselves".

(I am myself working these days on how to install larger projects such that 
after installation, after moving the installed directories around, including 
the directories that the build was done against, the code would still work. 
It's not trivial to do, but it's not impossible either. One just has to use 
$ in a clever way...)

Cheers,
   Attila

> On 30 Oct 2015, at 11:59, Nils Gladitz  wrote:
> 
> On 10/30/2015 11:32 AM, 李荣贵_dongnan wrote:
>> 
>> Recently, I use CMake to build the source code of a software in the platform 
>> of windows and I make it. However, I found if I move the whole file to other 
>> place, some errors will take place when the program run. According to the 
>> prompt information, I know CMake uses absolute path when building. Then I 
>> read a lot of relevant datum on the net. One solution is to open the 
>> variable “CMAKE_USE_RELATIVE_PATHS”. I have tried it and it doesn’t work. 
>> Someone also say this problem has not been effectively solved yet. I want to 
>> make this problem clear, so I decide to write this email.
>> 
> 
> CMAKE_USE_RELATIVE_PATHS has been removed from CMake [1]. Even before that 
> its use was not recommended.
> CMake build directories are not meant to be transferable or moved around; if 
> you need a build in a different location you will have to rerun cmake / the 
> build there.
> 
> Nils
> 
> [1] 
> https://cmake.org/gitweb?p=cmake.git;a=commit;h=1335992c8f4e8b96f1a21d5dcc7d65a9fbd84c11
> -- 
> 
> 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

[CMake] How to figure out the "type" of an imported library

[Attila Krasznahorkay]

Dear All,

In my code I'm trying to do something slightly tricky. I include packages that 
provide imported libraries (amongst other things). Then, because of how my 
project is structured, I don't make use of the imported libraries directly, but 
first make "copies" of them, and then make use of these copies in my build.

(The reason is that I allow the project to override libraries that are 
available from the base packages as well. In which case components using this 
overridden library need to use this instance instead of the imported one. But 
if no such override is in place, I need to give the library a name that the 
components in the project expect to find it with.)

If there would be a way in CMake to "clone" an imported library with a new 
name, that would be perfect for my use case. Since as far as I know there's no 
such thing, I use code like:

  ...
  add_library( ${libName} SHARED IMPORTED GLOBAL )
  # Check which builds it is available for:
  get_property( _builds TARGET ${prefix}_${libName}
 PROPERTY IMPORTED_CONFIGURATIONS )
  set_property( TARGET ${libName} PROPERTY
 IMPORTED_CONFIGURATIONS ${_builds} )
  ...

Now, I recently started producing MODULE and INTERFACE libraries as well. So 
the first line in this code is no longer correct for all the imported 
libraries. Plus, for INTERFACE libraries the get_property call on 
IMPORTED_CONFIGURATIONS just fails with an error message.

So now I wonder: Is there a target property on INTERFACE libraries that I could 
use to identify them? Like how there is the target property IMPORTED on the 
imported libraries.

Cheers,
Attila
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] How to figure out the "type" of an imported library

[Attila Krasznahorkay]

Thanks! It indeed looks like it will do the job.

Cheers,
 Attila

> On 29 Oct 2015, at 20:42, Tamás Kenéz <tamas.ke...@gmail.com> wrote:
> 
> There's a TYPE property which should contain what you need: 
> https://cmake.org/cmake/help/latest/prop_tgt/TYPE.html
> 
> On Thu, Oct 29, 2015 at 4:53 PM, Attila Krasznahorkay 
> <attila.krasznahor...@gmail.com> wrote:
> Dear All,
> 
> In my code I'm trying to do something slightly tricky. I include packages 
> that provide imported libraries (amongst other things). Then, because of how 
> my project is structured, I don't make use of the imported libraries 
> directly, but first make "copies" of them, and then make use of these copies 
> in my build.
> 
> (The reason is that I allow the project to override libraries that are 
> available from the base packages as well. In which case components using this 
> overridden library need to use this instance instead of the imported one. But 
> if no such override is in place, I need to give the library a name that the 
> components in the project expect to find it with.)
> 
> If there would be a way in CMake to "clone" an imported library with a new 
> name, that would be perfect for my use case. Since as far as I know there's 
> no such thing, I use code like:
> 
>   ...
>   add_library( ${libName} SHARED IMPORTED GLOBAL )
>   # Check which builds it is available for:
>   get_property( _builds TARGET ${prefix}_${libName}
>  PROPERTY IMPORTED_CONFIGURATIONS )
>   set_property( TARGET ${libName} PROPERTY
>  IMPORTED_CONFIGURATIONS ${_builds} )
>   ...
> 
> Now, I recently started producing MODULE and INTERFACE libraries as well. So 
> the first line in this code is no longer correct for all the imported 
> libraries. Plus, for INTERFACE libraries the get_property call on 
> IMPORTED_CONFIGURATIONS just fails with an error message.
> 
> So now I wonder: Is there a target property on INTERFACE libraries that I 
> could use to identify them? Like how there is the target property IMPORTED on 
> the imported libraries.
> 
> Cheers,
> Attila
> --
> 
> 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] Removing duplicate entries from CXXFLAGS

[Attila Krasznahorkay]

Hi Roman,

I'm not necessarily only talking about CMAKE_CXX_FLAGS here. I define compile 
flags for my targets in a number of different ways. Like:

   find_package( ROOT COMPONENTS ${ROOT_LINK_COMPONENTS} REQUIRED )
   include( ${ROOT_USE_FILE} )
...
   add_definitions( ${ATLAS_DEFINITIONS} )
...
   add_definitions( -Wno-unused-local-typedefs )
   if( APPLE )
  add_definitions( -Wno-tautological-undefined-compare )
  add_definitions( -Wno-inconsistent-missing-override )
   endif()
...
   include_directories( BEFORE ${CMAKE_CURRENT_SOURCE_DIR}
  ${CMAKE_INCLUDE_OUTPUT_DIRECTORY} )
   if( ARG_INCLUDE_DIRS )
  target_include_directories( ${libName} PUBLIC ${ARG_INCLUDE_DIRS} )
   endif()

The trickiest are the definitions that I pull in from external packages. For 
instance the second line in this example produces a *lot* of duplicate entries 
in the compilation flags. In this particular case the flags *are* defined like 
the following in the file that I include with ${ROOT_USE_FILE}:

add_definitions(${ROOT_DEFINITIONS})
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${ROOT_CXX_FLAGS}")

Now, CMake definitely doesn't remove the duplicates that enter in all these 
ways. So now I was wondering what I could do to improve on the situation...

Cheers,
   Attila

> On 06 Oct 2015, at 12:58, Roman Bolshakov <rool...@gmail.com> wrote:
> 
> CMake performs deduplication of per-target flags for sure.
> 
> However I'm not sure if CMAKE_CXX_FLAGS is deduplicated. But I consider this 
> variable as global flags for the whole project which is defined at topmost 
> CMakeLists.txt. If you need to specify some flags specifically for a target 
> use target_compile_options.
> 
> —
> Sent from Mailbox
> 
> 
> On Mon, Oct 5, 2015 at 4:23 PM, Attila Krasznahorkay 
> <attila.krasznahor...@gmail.com> wrote:
> 
> Dear All, 
> 
> Let me try a simpler question this time. (I'm a bit disappointed that nobody 
> had any comments on my question about sub-projects.) 
> 
> I'm trying to clean up my project's build a bit. As it collects compilation 
> flags from a few separate places, by the time it finishes collecting 
> everything, the compilation commands are usually very long. As they have many 
> duplications. Like: 
> 
> -m64 -pipe -W 
> -Wall -Woverloaded-virtual -fsigned-char -fno-common -Qunused-arguments 
> -pthread -std=c++11 -Wno-deprecated-declaration 
> s -stdlib=libc++ -m64 -pipe -W -Wall -Woverloaded-virtual -fsigned-char 
> -fno-common -Qunused-arguments -pthread -std=c++ 
> 11 -Wno-deprecated-declarations -stdlib=libc++ -Wno-unused-local-typedefs 
> -Wno-tautological-undefined-compare -Wno-incon 
> sistent-missing-override -m64 -pipe -W -Wall -Woverloaded-virtual 
> -fsigned-char -fno-common -Qunused-arguments -pthread 
> -std=c++11 -Wno-deprecated-declarations -stdlib=libc++ -m64 -pipe -W -Wall 
> -Woverloaded-virtual -fsigned-char -fno-commo 
> n -Qunused-arguments -pthread -std=c++11 -Wno-deprecated-declarations 
> -stdlib=libc++ -m64 -pipe -W -Wall -Woverloaded-vi 
> rtual -fsigned-char -fno-common -Qunused-arguments -pthread -std=c++11 
> -Wno-deprecated-declarations -stdlib=libc++ -m64 
> -pipe -W -Wall -Woverloaded-virtual -fsigned-char -fno-common 
> -Qunused-arguments -pthread -std=c++11 -Wno-deprecated-dec 
> larations -stdlib=libc++ -m64 -pipe -fsigned-char -fno-common 
> -Qunused-arguments -pthread -std=c++11 -stdlib=libc++ 
> 
> Naturally it would help the build log reading tremendously if I could remove 
> the duplications from these lines. But I can't find a good way of doing it. 
> How could I weed out all the duplications in the CXXFLAGS associated to a 
> given target? 
> 
> Cheers, 
> Attila 
> -- 
> 
> 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

[CMake] Removing duplicate entries from CXXFLAGS

[Attila Krasznahorkay]

Dear All,

Let me try a simpler question this time. (I'm a bit disappointed that nobody 
had any comments on my question about sub-projects.)

I'm trying to clean up my project's build a bit. As it collects compilation 
flags from a few separate places, by the time it finishes collecting 
everything, the compilation commands are usually very long. As they have many 
duplications. Like:

-m64 -pipe -W
 -Wall -Woverloaded-virtual -fsigned-char -fno-common -Qunused-arguments 
-pthread -std=c++11 -Wno-deprecated-declaration
s -stdlib=libc++ -m64 -pipe -W -Wall -Woverloaded-virtual -fsigned-char 
-fno-common -Qunused-arguments -pthread -std=c++
11 -Wno-deprecated-declarations -stdlib=libc++ -Wno-unused-local-typedefs 
-Wno-tautological-undefined-compare -Wno-incon
sistent-missing-override -m64 -pipe -W -Wall -Woverloaded-virtual -fsigned-char 
-fno-common -Qunused-arguments -pthread
-std=c++11 -Wno-deprecated-declarations -stdlib=libc++ -m64 -pipe -W -Wall 
-Woverloaded-virtual -fsigned-char -fno-commo
n -Qunused-arguments -pthread -std=c++11 -Wno-deprecated-declarations 
-stdlib=libc++ -m64 -pipe -W -Wall -Woverloaded-vi
rtual -fsigned-char -fno-common -Qunused-arguments -pthread -std=c++11 
-Wno-deprecated-declarations -stdlib=libc++ -m64
-pipe -W -Wall -Woverloaded-virtual -fsigned-char -fno-common 
-Qunused-arguments -pthread -std=c++11 -Wno-deprecated-dec
larations -stdlib=libc++ -m64 -pipe -fsigned-char -fno-common 
-Qunused-arguments -pthread -std=c++11 -stdlib=libc++

Naturally it would help the build log reading tremendously if I could remove 
the duplications from these lines. But I can't find a good way of doing it. How 
could I weed out all the duplications in the CXXFLAGS associated to a given 
target?

Cheers,
Attila
-- 

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] Associating a single build step with multiple sub-projects in CDash

[Attila Krasznahorkay]

Dear All,

After the suggestion from Bill Hoffman, I played with CDash for a while now. I 
was able to create a ctest script that would build the packages/subdirectories 
of my project one by one, and then upload the build/test results to a CDash 
server. With the results being quite user friendly on the webpage.

However this is unfortunately terribly slow. The project that I'm trying to 
build as an exercise has ~120 packages/subdirectories. Each with 1-20 source 
files. As you can imagine there's a huge difference between calling "make" just 
once to let all targets build at the same time, or to call it 120 times for the 
separate packages. The CPU utilisation in the latter case is less than 50% 
overall. (With the "Unix Makefiles" generator it's around 30%, and with Ninja 
around 50%. On an machine with 8 threads.)

But I noticed that when I build the project with CTEST_USE_LAUNCHERS enabled, 
even in a fully parallel build the output generated by CTest/CMake associates 
the build warnings/errors with the labels that I gave to the targets in my 
build. (Which correspond to the names of the packages.)

Unfortunately however I'm unable to upload the results from this single build 
step to CDash such that the warnings/errors belonging to the different 
sub-projects would show up under those sub-projects. :-( I tried this with the 
following code:

# Execute the project build:
ctest_build( BUILD ${CTEST_BINARY_DIRECTORY} APPEND )

# The subprojects to build/test:
set( _subprojects @CTEST_PROJECT_SUBPROJECTS@ )
foreach( _subproject ${_subprojects} )

   # Upload the build results for this package:
   set_property( GLOBAL PROPERTY SubProject Package_${_subproject} )
   set_property( GLOBAL PROPERTY Label Package_${_subproject} )
   set( CTEST_BUILD_TARGET Package_${_subproject} )
   ctest_submit( PARTS Build )

   # Execute the test(s) of the subproject:
   ctest_test( BUILD ${CTEST_BINARY_DIRECTORY}
  INCLUDE_LABEL Package_${_subproject} APPEND )
   ctest_submit( PARTS Test )

endforeach()

But this doesn't do what I was hoping for. (No filtering is made from the one 
big XML to just pick out the warnings/errors belonging to the currently 
processed package.)

Now, the current situation is already a lot better than I was in a few days 
ago. As the XML files generated by ctest in this case seem like a very good 
starting point to process using our nightly build system to present the 
warnings/errors on our privately produced webpages. But I wonder if it could be 
possible to also teach CTest/CDash how to do this sort of thing out of the 
box...

Cheers,
Attila
-- 

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] Build log generation in a "custom" way

[Attila Krasznahorkay]

Dear All,

I'd like to ask for some advice about the following issue. We're migrating a 
very big project (millions of lines of code...) from a custom build manager to 
CMake.

The software is put together from separate "packages" that are all developed by 
a different set of people. Our nightly build system collects all these 
packages, and compiles all of them. In our old build system we could easily 
save package-specific build log files for the nightly system. Making it easy 
for the developers to quickly find build problems in their specific package.

Now we'd like to do something similar with CMake. To teach it how to generate 
separate build log files for the separate packages. (Packages in this context 
are really just subdirectories in the end.) The clumsy thing that we're doing 
now is to use a script that we set for RULE_LAUNCH_COMPILE, RULE_LAUNCH_LINK, 
and RULE_LAUNCH_CUSTOM. This script writes log files in a non-too-perfect way, 
which need to be stitched together at the end of the build to get "package 
specific" build log files.

So the question is whether we could do something better. Does anyone have an 
idea/suggestion? I'm happy to give more information about our setup if needed.

Cheers,
  Attila
-- 

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