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

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

[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