Re: [cmake-developers] Problem with created debian package

[Domen Vrankar]

2017-12-30 6:29 GMT+01:00 Kornel Benko :

> > 2) use gnu tar instead by setting CPACK_DEBIAN_ARCHIVE_TYPE to gnutar
>
> Thanks, this is really nice. Meanwhile I found out what was going wrong.
> The package manager seems to not understand the way some filenames
> containing
> non-ascii chars are coded by cpack.
> I prepared a minimal example showing the effect here.
>
> 1.) Create a dir and copy the attached to it
> 2.) mkdir build; cd bild
> 3.) cmake .. -DCPACK_BINARY_DEB:BOOL=ON
> 4.) sudo dpkg -i wrongfilename-0.1.1-Linux.deb
> (Reading database ... 422665 files and directories currently
> installed.)
> Preparing to unpack wrongfilename-0.1.1-Linux.deb ...
> Unpacking wrongfilename (0.1.1) ...
> dpkg: error processing archive wrongfilename-0.1.1-Linux.deb
> (--install):
>  corrupted filesystem tarfile - corrupted package archive
> Errors were encountered while processing:
>  wrongfilename-0.1.1-Linux.deb
>

Thanks for the example.

The "use gnu tar option with CPack" produces a valid package for your
example:
set(CPACK_DEBIAN_ARCHIVE_TYPE "gnutar")

It would seem that non gnu version doesn't handle non ascii filenames
correctly. I'm not certain if it's an libarchive bug or expectedly
unsupported feature (it would seem that it's a bug...) - I'll have to
investigate further.

Thanks,
Domen
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Problem with created debian package

[Domen Vrankar]

2017-12-29 14:20 GMT+01:00 Kornel Benko :

> All of sudden, cmake(cpack) started producing wrong debian packages for
> one project.
>

Did the project change in some way or was it the packaging environment that
changed?
I'd like to know a bit more details even if the solution below works to
determine if this was a regression in CPack or something else.


> This is the output of debian package manager:
>
> dpkg: warning: downgrading lyx24 from 2.4.0-50424git-g3a4b233 to
> 2.4.0-50422git-gd6fb2ab
> (Reading database ... 422667 files and directories currently
> installed.)
> Preparing to unpack lyx24-2.4.0-50422git-Linux.deb ...
> Unpacking lyx24 (2.4.0-50422git-gd6fb2ab) over
> (2.4.0-50424git-g3a4b233) ...
> dpkg: error processing archive lyx24-2.4.0-50422git-Linux.deb
> (--install):
>  corrupted filesystem tarfile - corrupted package archive
> dpkg-deb: error: subprocess paste was killed by signal (Broken
> pipe)
> Errors were encountered while processing:
>  lyx24-2.4.0-50422git-Linux.deb
>
> Analysing the data.tar.gz gives no hint. What helps is a sequence of
> commands using the system's 'tar'.
>
> # ar xv  lyx24-2.4.0-50422git-Linux.deb  data.tar.gz
> # sudo tar axf data.tar.gz
> # tar cf data.tar ./usr
> # gzip -f data.tar
> # ar rv  lyx24-2.4.0-50422git-Linux.deb  data.tar.gz
>
> Now everything is OK.
> Other projects do not show this behaviour.
> This is cmake 3.10.20171229-g3e1f5b11, but the same happens with earlier
> version.
>

I'm surprised that this fixed the problem but from what you're describing
I'd say that some paths in the data tarball are too long for the paxr
version of tar to handle correctly (this is the default tar that is used by
CPack and debian packages as it is the most portable one).
If I'm right you could:

1) shorten the file paths in the archive
2) use gnu tar instead by setting CPACK_DEBIAN_ARCHIVE_TYPE to gnutar

See
https://cmake.org/cmake/help/v3.10/module/CPackDeb.html#variable:CPACK_DEBIAN_ARCHIVE_TYPE

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

Re: [cmake-developers] CMP0022 documentation is outdated

[Domen Vrankar]

2017-12-23 13:25 GMT+01:00 Alan W. Irwin :

> On 2017-12-19 14:18-0800 Alan W. Irwin wrote:
>
> I have a software project with a dated CMake-based build system that
>> specifically set CMP0022 to OLD.  So while updating that build system
>> I naturally consulted the latest CMP0022 documentation, e.g.,
>> > >, and
>> discovered that documentation was outdated, e.g.,
>> lots of historical references to CMake-2.8 which are likely no
>> longer needed, and the following recommendation
>>
>> Warning-free future-compatible code which works with CMake 2.8.7
>> onwards can be written by using the LINK_PRIVATE and LINK_PUBLIC
>> keywords of target_link_libraries().
>>
>> (The obvious problem with that advice is that LINK_PRIVATE and
>> LINK_PUBLIC are now deprecated themselves!)
>>
>> IF cmake-4 is coming soon and presuming that CMP0022 OLD behaviour
>> will no longer be supported by that version of cmake, then you may not
>> want to do anything about this outdated documentation since it will
>> be removed with cmake-4.
>>
>> But otherwise for current needs like mine (updating an old build system
>> that specifically set CMP0022 to OLD) a complete rewrite would
>> be a good idea with the emphasis on simplifying down to one
>> or two sentences such as
>>
>> Support for CMP0022 OLD behaviour is scheduled for removal with
>> cmake-4 [if that decision has indeed already been made] so do not set
>> this policy to OLD for new build systems.  But if you need to know
>> details about CMP0022 OLD behaviour in order to upgrade an old build
>> system that currently requires the OLD version of this policy, see the
>> target_link_libraries() documentation.
>>
>
> Hmm.  I got no responses to the above.  So I guess the conclusion is
> it's a very low priority to update the documentation of ancient
> policies like this one.  I guess that's fine if the plan is these
> ancient policies will finally be retired as of CMake-4 AND that new
> major version of CMake (which presumably will be allowed to break
> backwards compatibility) is coming reasonably soon.


I don't know what the plans regarding bumping CMake major version or
deprecating old policies are but I remember talks about deprecating some of
them on the mailing list - couldn't find the mails though... but found this
merger request that was already merged:
https://gitlab.kitware.com/cmake/cmake/merge_requests/743

It deprecates OLD policies for CMP0036 and below so the policy you are
talking about falls into that category.

You should raise an issue in CMake gitlab bug tracker:
https://gitlab.kitware.com
And perhaps also create merge request with the documentation changes/clean
up. The link you've provided already contains a note that OLD CMP0022 is
deprecated so perhaps it only needs deletion of some text or even deletion
of the entire text and replacing it with a note that policy no longer works
so it should not be used (maybe even deleting the policy from the code if
it still exists in there).

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

Re: [cmake-developers] [DISCUSSION] CMake Localization (L10N)

[Domen Vrankar]

2017-04-18 19:16 GMT+02:00 Konstantin Podsvirov :

> Draft code:
>
> > set(GREETING "greeting message" # Optional default value
> >  en "Hello, world!"
> >  ru "Привет, мир!")
> >
> > set(CMAKE_OUTPUT_LOCALE "en") # Or CMAKE_L10N_LOCALE...
> >
> > message("$L10N{GREETING}") # Hello, world!
> >
> > set(CMAKE_OUTPUT_LOCALE "fr")
> >
> > message("$L10N{GREETING}") # greeting text
> >
> > message("$L10N:ru{GREETING}") # Привет, мир!
>
> Any feedback?


Coming from a small country I'm not too keen on localization as it makes my
life harder - in case of an error I have to guess what the english version
of the error message would look like just to get results on Google.

I somewhat understand the wish of non programmers to see text in their own
language but for developers english is de facto programming standard
language so I don't see a reason for such an addition.

That being said I'd suggest a more generic alternative that can be used for
things other than localization:

Access by array position:
> set(GREETING "greeting message" "Hello, world!" "Привет, мир!")
> message(${GREETING}) # prints "greeting message"
> message(${GREETING:0}) # also prints "greeting message"
> message(${GREETING:1}) # prints "Hello, world!"
> message(${GREETING:2}) # prints "Привет, мир!"
where the underlying structure of GREETING is "greeting message;Hello,
world!;Привет, мир!"

Or taking that even further by defining maps:
> set(GREETING "greeting message" "en:Hello, world!" "ru:Привет, мир!")
> message(${GREETING}) # prints "greeting message"
> message(${GREETING:}) # also prints "greeting message"
> message(${GREETING:en}) # prints "Hello, world!"
> message(${GREETING:ru}) # prints "Привет, мир!"
where the underlying structure of GREETING is "greeting message;en:Hello,
world!;ru:Привет, мир!"

This could then be used for e.g. for creating enums e.g.:
> set(BUILD_TYPE_OPTIONS "default_flags" "Debug:debug_flags"
"Release:release_flags" ...)
> message("using flags:  ${CMAKE_BUILD_TYPE_OPTIONS:${CMAKE_BUILD_TYPE}}")
# error if outside of range (e.g. OddRelease was specified for
CMAKE_BUILD_TYPE)

For this to really be useful support for if() command would also be
required.

Regards,
Domen
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] not able to push topic to stage

[Domen Vrankar]

2016-12-20 18:02 GMT+01:00 Ben Boeckel <ben.boec...@kitware.com>:

> On Tue, Dec 20, 2016 at 17:50:02 +0100, Domen Vrankar wrote:
> > Has anything changed regarding how topics should be pushed to stage and
> > then to next for testing?
> >
> > When following what's written here: https://cmake.org/Wiki/CMake/
> Git/Develop
> > I get a git hook error:
> >
> > remote:
> > --
> > remote: denying cpack-deb-version-override-fix (64e9c38d) which contains
> > deny/topics/next (66805932)
> > remote:
>
> Your branch contains `next` in it. This is not allowed since your branch
> would then bring in all of the history `next` has into `master`.
>
> Are you trying to update your topic on `next`? Or base your branch on
> top of something on on `next`?
>

Oh... My mistake... Not certain how I managed to start from that branch.

Thanks,
Domen
-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] not able to push topic to stage

[Domen Vrankar]

Hi,

Has anything changed regarding how topics should be pushed to stage and
then to next for testing?

When following what's written here: https://cmake.org/Wiki/CMake/Git/Develop
I get a git hook error:

remote:
--
remote: denying cpack-deb-version-override-fix (64e9c38d) which contains
deny/topics/next (66805932)
remote:
--
remote: error: hook declined to update
refs/heads/cpack-deb-version-override-fix
To cmake.org:stage/cmake.git
 ! [remote rejected] HEAD -> cpack-deb-version-override-fix (hook declined)
error: failed to push some refs to 'g...@cmake.org:stage/cmake.git'

Thanks,
Domen
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] (Re-)Added RPM Suggested Dependency Support

[Domen Vrankar]

2016-11-04 14:15 GMT+01:00 Alexander Adam :

> On Freitag, 4. November 2016 09:34:46 CET you wrote:
>
> > Would you be willing to also write a test for the SUGGESTS tag?
> > The tests are located in Tests/RunCMake/CPack, you add the test to
> > RunCMakeTest.cmake and for an example of a test similar to what you'd
> need
> > to write you can search the CPack directory for all files containing
> > PER_COMPONENT_FIELDS in their name.
>
> I took the LONG_FILENAME test for deb packages as a template for the
> following
> patch. Is it more or less what you had in mind?
>

That was more or less what I needed, thanks.

I've made some changes to the patch and test and also extended it to work
correctly for some tags that are not listed by rpmbuild --querytags.

The topic is now in next for testing:
https://cmake.org/gitweb?p=cmake.git;a=commit;h=838fd5c

Thanks,
Domen
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] (Re-)Added RPM Suggested Dependency Support

[Domen Vrankar]

>
> after searching how to use the documented
> CPACK_RPM__PACKAGE_SUGGESTS feature, I stumbled across the
> following ticket: https://gitlab.kitware.com/cmake/cmake/issues/13423
>
> After reading through the discussion, I tried to fix the remaining issues
> and
> came up with the attached patch (against master). I also added the patched
> CPackRPM.cmake for security.
>

At first glance I like the solution. I'll take a more detailed look at it
in the afternoon.

Would you be willing to also write a test for the SUGGESTS tag?
The tests are located in Tests/RunCMake/CPack, you add the test to
RunCMakeTest.cmake and for an example of a test similar to what you'd need
to write you can search the CPack directory for all files containing
PER_COMPONENT_FIELDS in their name.

Thanks,
Domen
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Linux PGI compiler missing --build-id flag by default

[Domen Vrankar]

> On 09/23/2016 06:47 AM, Domen Vrankar wrote:
> > I have rpm tests failing on dashboard [1] and it would seem that PGI
> compiler
> > is missing --build-id flag by default which can be added [2]
> >
> > Is this default behavior (missing --build-id flag) intended or simply
> missing from CMake?
> >
> > I'm guessing that this is a linker option (or do I also need a compiler
> flag?) so how do
> > I add it only for this compiler? Which|CMAKE_CXX_COMPILER_ID value
> should I compare
> > to or should I use a different CMake variable?
>
> Is this flag needed in general or only for your test?
>

This is mandatory for rpm debug info packages but as far as I can tell it
only serves for easier identification of binaries/shared libs for debugging
and dump analysis...
I was wondering if this is mandatory on Linux since I didn't even know
until today that this option exists (seems to always be set with gcc/clang).

If nobody else is missing this flag I'll just add the flag in
'if(CMAKE_CXX_COMPILER_ID MATCHES "PGI")' block for this test for now and
explain it in CPackRPM docs.

Thanks,
Domen
-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] Linux PGI compiler missing --build-id flag by default

[Domen Vrankar]

Hi all,

I have rpm tests failing on dashboard [1]

and it would seem that PGI compiler is missing --build-id flag by default
which can be added [2]

.

Is this default behavior (missing --build-id flag) intended or simply
missing from CMake?

I'm guessing that this is a linker option (or do I also need a compiler
flag?) so how do I add it only for this compiler? Which CMAKE_CXX_COMPILER_ID
value should I compare to or should I use a different CMake variable?

Thanks,
Domen

[1]
https://open.cdash.org/testSummary.php?project=1=RunCMake.CPack_RPM=2016-09-22

[2]
http://www.pgroup.com/userforum/viewtopic.php?p=11665=330354c1739f0409fd1be6878830b457
-- 

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] Some CPackRPM Debug print is printing without DEBUG On

[Domen Vrankar]

> Doh. Less haste more speed. Thanks. Patch 2.

Pushed to next:
https://cmake.org/gitweb?p=cmake.git;a=commit;h=49df5d480045ea77295825f2968ec57c4146b5d8

Thanks,
Domen
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Some CPackRPM Debug print is printing without DEBUG On

[Domen Vrankar]

2016-07-11 13:50 GMT+02:00 Harry Mallon :
> I get this line printed a lot even without CPACK_RPM_PACKAGE_DEBUG turned on.
>
> "CPackRPM:Debug: Adding 
> /usr/lib/systemd;/usr/lib/systemd/system;/usr/lib/systemd/system-preset;/usr/lib/udev;/usr/lib/udev/rules.d;/usr/etc;/etc/security;/etc/security/limits.d
>  to builtin omit list."
>
> Patch attached

Provided patchi disables both debug message as well as
CPACK_RPM_EXCLUDE_FROM_AUTO_FILELIST functionality. That if statement
should not be changed and instead a new if statement wrapping only
message should be added.

Regards,
Domen
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Productbuild CPack generator

[Domen Vrankar]

> Does anyone here know if we have test coverage already for some cpack
> generators where we create a package, then unpack it to verify the results?
>

Tests/CPackComponentsDEB (Deb), Tests/CPackComponentsForAll (RPM) and tests
in Tests/RunCMake/CPack (at the moment Deb, RPM, TGZ) all verify content of
generated packages.

I intended for Tests/RunCMake/CPack to be the location of all tests for
CPack generated packages that can be verified with command line tools in a
way that you specify the type of test and if other generators have the same
capabilities they should use the same test with additional generator
specific variables in a separate file.
Unfortunately atm there are still some issues with those tests with the
most annoying being the verbosity because of:
- test should automatically cover different packaging styles [monolithic,
components, ...],
- for most tests files count and content should be the same with each
generator's Helpers.cmake providing the format (at the moment each test has
to provide special ExpectedFiles cmake script so it's too complicated to
write tests)

It's on my TODO list to extend Tests/RunCMake/CPack so hopefully I'll get
to it in the following week or two.
If you'd like to add your tests to it there is a README.txt file there that
explains how it works and how to add your own tests to it.

Regards,
Domen
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Make CPACK_RPM_PACKAGE_RELEASE match Fedora/RHOS/CentOS recommended behaviour

[Domen Vrankar]

> That is infinitely simpler. Looks like a good addition to me.
>
>
Applied to next:
https://cmake.org/gitweb?p=cmake.git;a=commit;h=d758f12

Thanks,
Domen
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Make CPACK_RPM_PACKAGE_RELEASE match Fedora/RHOS/CentOS recommended behaviour

[Domen Vrankar]

Sorry for the late reply.

Here is another go. I have added a 3rd variable but I think it means that
> current behaviour is continued and your input (thanks Dolf and Romen) has
> been addressed.
>
> https://github.com/hm1992/CMake/commit/2f54442388ab767f60fcb8cde1db2236ae535080
>

I'm somewhat reluctant to add yet another CPACK_RPM_* variable to an
already long list as it doesn't add much value - RPMBUILD-DEFAULT
functionality could just as easily be added to CPACK_RPM_DIST variable
without breaking the back compatibility.

I took a better look at the documentation that you were referring to (
https://fedoraproject.org/wiki/Packaging:DistTag) and noticed this section:

   - You must not override the variables for %{dist} (or any of the related
   variables).
   - You must not hardcode a value for %{dist} (or any of the related
   variables) in your spec.
   - You must not hardcode a dist tag in the spec: *BAD:* Release: 1.fc20
   *GOOD:* Release: 1%{?dist}
   - You cannot put any sort of "tagging" in %{dist} (or any of the related
   variables). %{dist} (and its related variables) exist ONLY to define the
   distribution that a package was built against.

It would seem that overriding dist tag is unsupported and prohibited.

I've changed the patch with that in mind. Would the attached patch be OK
for you?
Thanks,
Domen
From 1091950f7ecabcaf283afbf3e36e357d1cd5b00b Mon Sep 17 00:00:00 2001
From: Harry Mallon 
Date: Wed, 11 May 2016 11:21:11 +0200
Subject: [PATCH 1/1] CPack/RPM release dist tag support

Some Linux distros require Release tag
to be set to .
---
 Modules/CPackRPM.cmake | 27 ---
 1 file changed, 24 insertions(+), 3 deletions(-)

diff --git a/Modules/CPackRPM.cmake b/Modules/CPackRPM.cmake
index 768d64f..330fc1e 100644
--- a/Modules/CPackRPM.cmake
+++ b/Modules/CPackRPM.cmake
@@ -80,10 +80,27 @@
 #
 #  This is the numbering of the RPM package itself, i.e. the version of the
 #  packaging and not the version of the content (see
-#  CPACK_RPM_PACKAGE_VERSION). One may change the default value if the
-#  previous packaging was buggy and/or you want to put here a fancy Linux
+#  :variable:`CPACK_RPM_PACKAGE_VERSION`). One may change the default value if
+#  the previous packaging was buggy and/or you want to put here a fancy Linux
 #  distro specific numbering.
 #
+# .. note::
+#
+#  This is the string that goes into the RPM ``Release:`` field. Some distros
+#  (e.g. Fedora, CentOS) require ``1%{?dist}`` format and not just a number.
+#  ``%{?dist}`` part can be added by setting :variable:`CPACK_RPM_PACKAGE_RELEASE_DIST`.
+#
+# .. variable:: CPACK_RPM_PACKAGE_RELEASE_DIST
+#
+#  The dist tag that is added  RPM ``Release:`` field.
+#
+#  * Mandatory : NO
+#  * Default   : OFF
+#
+#  This is the reported ``%{dist}`` tag from the current distribution or empty
+#  ``%{dist}`` if RPM macro is not set. If this variable is set then RPM
+#  ``Release:`` field value is set to ``${CPACK_RPM_PACKAGE_RELEASE}%{?dist}``.
+#
 # .. variable:: CPACK_RPM_PACKAGE_LICENSE
 #
 #  The RPM package license policy.
@@ -1317,7 +1334,11 @@ function(cpack_rpm_generate_package)
   # This is the case when the packaging is buggy (not) the software :=)
   # If not set, 1 is a good candidate
   if(NOT CPACK_RPM_PACKAGE_RELEASE)
-set(CPACK_RPM_PACKAGE_RELEASE 1)
+set(CPACK_RPM_PACKAGE_RELEASE "1")
+  endif()
+
+  if(CPACK_RPM_PACKAGE_RELEASE_DIST)
+set(CPACK_RPM_PACKAGE_RELEASE "${CPACK_RPM_PACKAGE_RELEASE}%{?dist}")
   endif()
 
   # CPACK_RPM_PACKAGE_LICENSE
-- 
2.7.4

-- 

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] Make CPACK_RPM_PACKAGE_RELEASE match Fedora/RHOS/CentOS recommended behaviour

[Domen Vrankar]

2016-05-06 19:09 GMT+02:00 Harry Mallon :

> According to Fedora documentation the "Release:" variable in RPM files
> should be set to 1%{?dist}.
> https://fedoraproject.org/wiki/How_to_create_an_RPM_package
> https://fedoraproject.org/wiki/Packaging:DistTag
>
> This means it should be set to a string which looks like "1.el7.centos" on
> my CentOS7 machine. CPack sets this to "1" by default, but can be changed
> with the CPACK_RPM_PACKAGE_RELEASE variable. I propose a change as follows:
>
> https://github.com/hm1992/CMake/commit/94c611d5710a51072e15855ed96a225def975c38
>
> * Adds CPACK_RPM_DIST which defaults to the output of "rpmbuild -E %{dist}
> 2>/dev/null".
> * Makes CPACK_RPM_PACKAGE_RELEASE default to "1${CPACK_RPM_DIST}"
>
> I think I am right in saying this would not change behaviour on
> distributions that did not use the %{dist} option as "rpmbuild -E
> %{dist}" should return nothing.
>

Hi,

dist tag looks like a good addition however there are some issues with the
proposed patch:

- As Rolf already mentioned "2>/dev/null" should be replaced with
ERROR_QUIET and also OUTPUT_STRIP_TRAILING_WHITESPACE

- there is no need to check for the existance of rpmbuild as that is
already checked at the top of cpack_rpm_generate_package function

- rpmbuild -E %{dist} should use %{?dist} to check if tag is set otherwise
%{dist} will be printed out instead of an empty string on platforms that
don't set this tag

- CPACK_RPM_DIST is only applied in situations when
CPACK_RPM_PACKAGE_RELEASE is not set by the user

To solve the last bullet I would propose that you extend the patch so that
with CPACK_RPM_DIST:

- if not set current functionality would remain (${CPACK_RPM_PACKAGE_RELEASE}
only - I would not make an exception for "1${CPACK_RPM_DIST}" default value)

- if set to value "RPMBUILD-DEFAULT" rpmbuild -E %{?dist} would be used to
get CPACK_RPM_DIST value and then appended to CPACK_RPM_PACKAGE_RELEASE

- if set to any other value that value would be used (also a check would
have to be made that if first character is not a dot it has to be added
automatically)

Thanks,
Domen
-- 

Powered by www.kitware.com

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

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

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

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

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

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

[Domen Vrankar]

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

I've added warning message to the patch.

Patch is now on next branch:
https://cmake.org/gitweb?p=cmake.git;a=commit;h=5e5d0ab

Thanks,
Domen


  https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail_term=oa-2115-v2-b;
target="_blank">https://ipmcdn.avast.com/images/2016/icons/icon-envelope-tick-round-orange-v1.png;
/>
Virus-free. https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail_term=oa-2115-v2-b;
target="_blank" style="color: #4453ea;">www.avast.com



-- 

Powered by www.kitware.com

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

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

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

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

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

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

[Domen Vrankar]

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.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
>>>>
>>>
>
#.rst:
# CPackRPM
# 
#
# The builtin (binary) CPack RPM generator (Unix only)
#
# Variables specific to CPack RPM generator
# ^
#
# CPackRPM may be used to create RPM package using CPack.
# CPackRPM is a CPack generator thus it uses the ``CPACK_XXX`` variables
# used by CPack : https://cmake.org/Wiki/CMake:CPackConfiguration.
#
# CPackRPM has specific features which are controlled by the specifics
# :code:`CPACK_RPM_XXX` var

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

[Domen Vrankar]

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
:
> 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  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] [CPackRPM] Configure RPM package group and name per component

[Domen Vrankar]

2015-11-17 9:18 GMT+01:00 Domen Vrankar <domen.vran...@gmail.com>:
> 2015-11-15 20:32 GMT+01:00 Markus Rickert <rick...@fortiss.org>:
>> Hi,
>>
>> similar to the previous patch for CPackDeb, the attached patch adds
>> component-specific settings for group and name of an RPM package.
>>
>> CPACK_RPM__PACKAGE_GROUP allows setting the group of the
>> component with the main libraries to "Development/Libraries", while
>> "Documentation" can be used for the component with the actual documentation.
>>
>> CPACK_RPM__PACKAGE_NAME can set the package name (not the
>> filename) of a component, e.g., "foo" for libraries (instead of
>> "foo-libraries") and "foo-devel" for headers.
>
> I'll try to review it today.

Sorry for this delay...

Applied patch with minor change:
https://cmake.org/gitweb?p=cmake.git;a=commit;h=c926efa

Thanks,
Domen
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [CPackRPM] Configure RPM package group and name per component

[Domen Vrankar]

2015-11-15 20:32 GMT+01:00 Markus Rickert :
> Hi,
>
> similar to the previous patch for CPackDeb, the attached patch adds
> component-specific settings for group and name of an RPM package.
>
> CPACK_RPM__PACKAGE_GROUP allows setting the group of the
> component with the main libraries to "Development/Libraries", while
> "Documentation" can be used for the component with the actual documentation.
>
> CPACK_RPM__PACKAGE_NAME can set the package name (not the
> filename) of a component, e.g., "foo" for libraries (instead of
> "foo-libraries") and "foo-devel" for headers.

I'll try to review it today.

Thanks,
Domen
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [ANNOUNCE] CMake 3.4.0 Released

[Domen Vrankar]

2015-11-12 22:52 GMT+01:00 Jean-Michaël Celerier
:
>> * The "CPackDeb" module now correctly excludes symlinks during
>   package checksum calculation.
>
>> * The "CPackDeb" no longer uses fakeroot and system tar program for
>   packaging.
>
> Does this mean that the ubuntu package manager will stop complaining of
> CPack DEBs ?

As the author of those patches announced the packages can even be
built for Launchpad:
https://www.mail-archive.com/cmake-developers%40cmake.org/msg14723.html

The packages can be created to pass lint tests but there are no
convenience functions that would create a license file and such so
only setting package components in install commands, adding deb
package generator and create package won't produce a package that
would pass lintian tests.
So yes it can be done but for now it's not as straight forward as it could be.

Regards,
Domen
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [CPackDeb] Configure Debian package name for components

[Domen Vrankar]

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

Indeed these seem to be two separate issues.

I've applied your patch for CPACK_DEBIAN__PACKAGE_NAME with
some minor changes:
https://cmake.org/gitweb?p=cmake.git;a=commit;h=3fd6cb7

Regards,
Domen
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [CPackDEB] handling "Source" field and Launchpad support

[Domen Vrankar]

> Thanks.  There are several .rst documentation updates like:
>
>> -# CPackDeb is a CPack generator thus it uses the CPACK_XXX variables
>> +# CPackDeb is a CPack generator thus it uses the `CPACK_XXX` variables
>
> This appears to intend to use inline markup for inline literals but
> that is markdown syntax.  For reStructuredText it should be of the
> form ``CPACK_XXX``.  Please revised.

Fixed:
https://cmake.org/gitweb?p=cmake.git;a=commit;h=f2d98e2
https://cmake.org/gitweb?p=cmake.git;a=commit;h=e5b70ed

Thanks,
Domen
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] CMake 3.4.0-rc2 cpack xz compressed debian packages broken

[Domen Vrankar]

2015-11-03 10:53 GMT+01:00 Raffi Enficiaud :
> Le 23/10/15 17:04, Brad King a écrit :
>>
>> On 10/23/2015 06:04 AM, Raffi Enficiaud wrote:
>>>
>>> Fix attached! (based on current master a03c13a)
>>
>>
>> Thanks.  I backported it to 'release' and applied:
>>
>>   CPackDEB: Use proper compression scheme for control.tar.gz
>>   https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=66178ae5
>>
>>> PS.: I will add the test later today
>>
>>
>> Great.  We can add that when ready.
>
>
> Sorry for the delay.
>
> Please find attached a test that fires the bug (failure with dpkg-deb). It
> is based your previous commit, 66178ae.

Great thanks.
Applied to next: https://cmake.org/gitweb?p=cmake.git;a=commit;h=341cd93

Since this is only a test (bug fix was already merged to release) I
doubt that this patch must be backported to release.

Thanks,
Domen
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [CPackDEB] handling "Source" field and Launchpad support

[Domen Vrankar]

> Please find attached a patch that enables the proper handling of the
> "Source" field for binary Debian packages.

I've split the patch and applied it to next with minor changes:
https://cmake.org/gitweb?p=cmake.git;a=commit;h=0cb1469
https://cmake.org/gitweb?p=cmake.git;a=commit;h=76f0fd0

> I have successfully used the patch (and all the previous developments on
> CPackDEB) to generate my little C++ project on Launchpad from a GIT
> repository (check the packages content):

Great to hear that! Thanks for all your contributions to CPackDEB that
made this possible.

Thanks,
Domen
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [CPack][BUG] Fail to package with CPACK_INSTALLED_DIRECTORIES

[Domen Vrankar]

2015-09-24 9:06 GMT+02:00 Domen Vrankar <domen.vran...@gmail.com>:
> 2015-09-23 17:00 GMT+02:00 CHEVRIER, Marc <marc.chevr...@sap.com>:
>> Any comments about this problem?

There was a bug in file creation time handling. Fix is in cmake git
repository on next branch:
http://cmake.org/gitweb?p=cmake.git;a=commit;h=39347d3

Could you check if it works for you?

Thanks,
Domen
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [CPack][BUG] Fail to package with CPACK_INSTALLED_DIRECTORIES

[Domen Vrankar]

2015-09-23 17:00 GMT+02:00 CHEVRIER, Marc :
> Any comments about this problem?

Sorry I've forgotten about this mail... From what you're describing it
should work. I'll take a look later today and get back to you then.

Thanks,
Domen
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [CPackDeb] empty directories in packages

[Domen Vrankar]

> I was looking at this issue
> http://public.kitware.com/Bug/view.php?id=13009
>
> and apparently it is not possible to install empty directories (I just
> tested).
>
> I believe that it should be possible to do that (even if there are better
> ways like postinst).
> What is your opinion?

I agree. This is also an issue on other packaging generators (e.g. tar gz)

> The attached patch addresses this (and adds the corresponding test). It is
> based on my previous patch
> "0001-CPackDeb-preventing-md5sum-on-symlinks.patch".

Thanks, applied to next for testing:
http://www.cmake.org/gitweb?p=cmake.git;a=commit;h=47b060

Your patch only fixed the issue for component packaging so I extended
it to non component packaging as well. This also fixes the issue for
other generators:
http://www.cmake.org/gitweb?p=cmake.git;a=commit;h=b58de9f

Other fixed bug reports:
http://public.kitware.com/Bug/view.php?id=8767 and
http://public.kitware.com/Bug/view.php?id=14978


Thanks,
Domen
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [CPackDeb] empty directories in packages

[Domen Vrankar]

> You left a commented out line in Source/CPack/cmCPackGenerator.cxx.

Hm that should not be there. I'll delete it when I get to my PC.

Thanks,
Domen
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [PATCH] CPack: add a new setting, CPACK_VERBATIM_VARIABLES

[Domen Vrankar]

2015-09-20 20:03 GMT+02:00 Роман Донченко :
> If it's set to a true value, CPack will escape all variables for the CMake
> parser when writing them out to configuration files. This parallels the
> VERBATIM argument to add_custom_command.
>
> The cpack_encode_variables macro is changed into a function to remove
> scope pollution. There should be no other effects.

Applied with minor variable description changes to next for testing:
http://www.cmake.org/gitweb?p=cmake.git;a=commit;h=bc2e54d

Thanks,
Domen
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [CPackDeb] use of internal md5sum function

[Domen Vrankar]

> Please find attached a patch on CPackDeb
> - which calls the internal function for md5sum computation
> - which prevents the hash of the symlinks
>
> I believe this fixes the issue (partially or totally)
>
> https://public.kitware.com/Bug/view.php?id=13386
>

Applied with minor changes to lintian test result verification:
http://www.cmake.org/gitweb?p=cmake.git;a=commit;h=7c7874c8

Thanks,
Domen
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [CPackDeb][libarchive] removing use of fakeroot and supporting UID/GID/UNAME etc in libarchive

[Domen Vrankar]

> Please find attached the "feature" based onto 68dba7f. I added the variable
> CPACK_DEBIAN_PACKAGE_CONTROL_STRICT_PERMISSION and its component counterpart
> for controlling strict behaviour on the files added to control.tar.gz .

Thanks, applied and squashed patches with some changes to
cmArchiveWrite as it was causing compiler warnings regarding signed
unsigned conversions:
http://www.cmake.org/gitweb?p=cmake.git;a=commit;h=3b099fd

> PS.: what about the other patches?

I'll apply them as soon as this feature is merged to master.

Thanks,
Domen
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [CPackDeb][libarchive] removing use of fakeroot and supporting UID/GID/UNAME etc in libarchive

[Domen Vrankar]

2015-09-14 23:49 GMT+02:00 Raffi Enficiaud <raffi.enfici...@mines-paris.org>:
> Le 14/09/15 23:34, Domen Vrankar a écrit :
>>>
>>> Thank you. However those two test are not mutually exclusive. I think
>>> having
>>> them on lintian is also a good thing.
>>
>>
>> I've tried your test change before but lintian test complained that
>> 775 are invalid permissions (should be 755). Is this caused by a
>> different version of lintian or should I just modify your test to use
>> 755 permissions and apply that?
>>
>
> That's very good that it fails :)
>
> I tested on Ubuntu 14.04, maybe Debian distributions are even more strict.
> Apparently the files that "file(WRITE ...)" created on your system are with
> 775. I believe the problem lies in the "file(" commands rather than on a
> different version of lintian.
>
> OTOH, I can see from this:
>
> https://lintian.debian.org/tags/control-file-has-bad-permissions.html
>
> that all files should have at least a permission mask set to ~S_IWGRP &
> ~S_IWOTH (with "control_tar.SetPermissionsMask(~S_IWGRP & ~S_IWOTH)"), so
> that the executable bit is left unchanged and the write bit is cleared for
> group and others (755 and 644).
>
> What do you think?

You are correct. I've reinstalled my virtual machine and retested with
"control_tar.SetPermissionsMask(~S_IWGRP & ~S_IWOTH)" and it would
seem that there was an issue in my testing environment - before this
did not work as expected on my machine. Same goes for default
permissions being 664/775 instead of 644/755.

I would keep md5 checksum file permissions on 644 with SetPermissions
and add SetPermissionsMask from above for the rest of control files.
Would you agree?

Thanks,
Domen
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [CPackDeb][libarchive] removing use of fakeroot and supporting UID/GID/UNAME etc in libarchive

[Domen Vrankar]

> From this (thanks to lintian now I have the proper link :) )
>
> https://lintian.debian.org/tags/control-file-has-bad-permissions.html
> https://www.debian.org/doc/debian-policy/ch-files.html#s-permissions-owners
>
> all control files:
> - should be owned by root:root (+ I would say uid/gid 0/0, because root may
> be mapped) which is the case now
> - should be 755 or 644, depending if they are executable or not
>
> The number of files that should be 755 are limited to (according to
> linitian) config, postinst, postrm, preinst, and prerm. All others should be
> 644.
>
> So I would say without loss of generality, we can set the permission to 644
> except for those config, postinst... files . I can send you a patch based on
> 76c59007dd3944e23848b7d5912a59a7d3db6398 today (and update the doc
> accordingly).
>
> Is that good for you?

Sounds good.
Those rules are written as guidelines and I'm not certain how often
they are broken so could you also add a single variable for toggling
between defaults described above and using file permissions as
provided?

Thanks,
Domen
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [CPackDeb][libarchive] removing use of fakeroot and supporting UID/GID/UNAME etc in libarchive

[Domen Vrankar]

>> I just realized that the permissions for the extra control files should
>> be set in a different way than for the md5sum checksum file.
>>
>> Please find attached the patch correcting this and the corresponding
>> test that fires the problem.

Thanks, applied the fix:
http://www.cmake.org/gitweb?p=cmake.git;a=commit;h=68dba7f

I've extended RunCMake.CPack_DEB DEB_EXTRA test instead of using your
test as I am trying to put new tests there.

Thanks,
Domen
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [CPackDeb][libarchive] removing use of fakeroot and supporting UID/GID/UNAME etc in libarchive

[Domen Vrankar]

> Thank you. However those two test are not mutually exclusive. I think having
> them on lintian is also a good thing.

I've tried your test change before but lintian test complained that
775 are invalid permissions (should be 755). Is this caused by a
different version of lintian or should I just modify your test to use
755 permissions and apply that?

Regards,
Domen
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [CPackDeb][libarchive] removing use of fakeroot and supporting UID/GID/UNAME etc in libarchive

[Domen Vrankar]

> I have made the following changes in order to:
> - support the UID/GID/UNAME/GNAME and permission on tar files at creation
> time
> - using directly libarchive in CPackDeb
> - removing completely the need of fakeroot

Applied to next for testing:
http://www.cmake.org/gitweb?p=cmake.git;a=commit;h=2e9af45

I've fixed permission mask code in patch 2 and 3. Please confirm that
it works OK in your environment.

I've also removed permission mask setting for directories and files as
I am not certain that it belongs there - it wasn't there before and
user can always change permissions with install command. Issue with
default permissions being 775 is system default related and occurs
only with directories that are automatically created - directories
created with install command get permission 755 which is acceptable
for deb packages.
I believe that this inconsistency should be fixed elsewhere by adding
possibility to set global default directory permissions.

> Is it on time for 3.4 freeze?

Feature freeze was announced for Oct, 1 so it should make it in 3.4

Regards,
Domen
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [PATCH] CPack: don't mangle CMake-special characters when applying default settings

[Domen Vrankar]

2015-09-03 22:00 GMT+02:00 Роман Донченко :
> By using a function to do it instead of a macro. Deprecate the old macro,
> but keep it for backwards compatibility. Remove existing workarounds for this
> problem and add a test.

Applied with minor changes to next for testing:
http://www.cmake.org/gitweb?p=cmake.git;a=commit;h=2a7772f

Thanks,
Domen
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [PATCH] Add a test for checking that the CPack module produces correct config files

[Domen Vrankar]

> My motivation is this. I want to submit a few improvements to the way CPack
> writes config files, starting with that cpack_set_if_not_set change I
> mentioned a while back. This functionality is generator-independent (and
> basically unrelated to actual package generation), so I thought
> RunCMake.CPack was not the appropriate place to test it.

Yes you're right, RunCMake.CPack is meant for specific generators and
adding target 'none' or something similar would just make a mess.

> Since there doesn't seem to be a test suite specifically for config file
> writing, I thought I'd create one in a separate patch so that my later
> patches don't have as much boilerplate in them. The Simple test is just
> there to ensure I don't break the simple case while changing the more
> complex ones. Well, and it would be silly to submit a test suite with no
> tests in it.

I've added your test:
http://www.cmake.org/gitweb?p=cmake.git;a=commit;h=674dc0b

Thanks,
Domen
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [PATCH] Add a test for checking that the CPack module produces correct config files

[Domen Vrankar]

Hi,

I apologise for the late reply. I wasn't at my computer for the past week.

2015-08-19 21:08 GMT+02:00 Роман Донченко d...@corrigendum.ru:
 Currently, the only case is for simple variable values (not containing any
 CMake-special characters and not determined by CPack itself).

In CPackRPM and CPackDeb both cases that this is testing (CMake list
variable and a variable containing spaces) are already tested
implicitly. RunCMake.CPack contains such test. Admittedly both cases
are not present in same variable.

Your test passes on my computer.

Is this test targeting a particular CPack generator or a CMake-CPack
bug on a particular OS?

Regards,
Domen
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [CPack] CPackDeb and fakeroot

[Domen Vrankar]

Hi,

I see that I'm a bit late to the party... Wasn't at my computer for
the past few days.

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


 Again two solutions:
 - using system tar with the proper uid/gid options
 - using and tweaking libarchive directly

I haven't used uid/gid options in libarchive so I'm not certain what
it's capabilities are but if possible I'd definitely go with
libarchive.

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


 I agree.

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

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


 Ok, I just had a look to the cmlibarchive, cmakelib and cpackdeb sources,
 it's not such a big deal neither to support that functionality.

 One question remains though: in case of lzma or xy compression, cmake -E tar
 is not used, and system tar is used instead (lines 414 in
 cmCPackDebGenerator.cxx). This looks different from what you mentioned about
 the BSD ar format using ar_append at the end of the same function.
 LZMA and xy are supported by libarchive, so it should be possible to avoid
 any call to tar or cmake -E in all cases.

Since lzma and xz are also using fakeroot and for consistency I'd go
with with libarchive here as well.
I'm guessing that the only reason these two compression formats were
treated as special cases was because of lack of support in CMake in
the past:
http://www.cmake.org/Bug/view.php?id=13072

but this was resolved more than a year ago.

Regards,
Domen
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Add command line options for deprecation message control

[Domen Vrankar]

 The branch seems to make the RunCMake.CPack_RPM test fail on my machine. I
 have not investigated.

Missed this thread... I was talking to Brad about this.
Failing test is written exactly for testing author warning message
(CPackRPM.cmake:560). RPM packages may be relocatable but if
relocation paths don't match with any file paths in package an author
warning is output but package is still created.

Since CPack only gets CPACK_* variables from CMake we can't use
CMAKE_SUPPRESS_DEVELOPER_ERRORS to revert back to warnings. If this is
the only location where CPack uses developer messages we could change
it to normal info message but implementing this fallback mechanism for
CPack (and CTest?) would probably be a more complete solution.

Regards,
Domen
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] CMake Build RPM for Centos/RHEL

[Domen Vrankar]

 2. Is there a way to generate a RPM with standard name:
 I mean, something like:  cmake-3.2.3-1.el6.x86_64.rpm
 Instead of:  cmake-3.2.3-Linux-x86_64.rpm

You can add
-D CPACK_OUTPUT_FILE_NAME=cmake-${RPM_RELEASE}.el6.x86_64.rpm

to your packaging command. This will force package name.
Forcing the name will cause a CPack error:
CPack Error: Problem copying the package

but at that point the package was already created - you just have to
find it as it wasn't copied from rpmbuild dir to cmake root dir:

find . -name *.rpm | xargs -i{ cp { ./

 3. I tried what I built, but:
 CMake Error: Could not find CMAKE_ROOT !!!
 CMake has most likely not been installed correctly.
 Modules directory not found in
 /usr/share/cmake-3.2
 CMake Error: Error executing cmake::LoadCache(). Aborting.


 Problem is that the created directory exists but it can't be read 
 because of permissions:   drwxr-x---.

That's odd... If I run the command below on rpm created from cmake
repository master branch I get different permissions:

rpm -qp --qf [%-15{=NAME} %-36{FILENAMES} %{FILEMODES:perms}\n]
cmake-3.3.20150607-gcb1a9-Linux-x86_64.rpm | grep Modules 
cmake   /usr/share/cmake-3.3/Modules drwxr-xr-x


Regards,
Domen
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] A policy for Policies

[Domen Vrankar]

 And do we really still need version 2.6 as default (we could bump this
 version to where current policies are still treated as warnings not
 errors)?

 To which default do you refer?  Where in our code is it set?
 Likely we cannot update it because it could change behavior
 of existing scripts with no transition warning ever given.

I've read it in Mastering CMake and had to search for it today...  On
page 42 it says that by default if cmake_minimu_required is missing it
sets policy version of 2.4.

It's probably a technical back compatibility reason
(cmake_minimum_required wasn't present back then?) and those scripts
don't necessarily use any of the policies that will change but I was
wondering if changing this to a newer version (2.6.8?) would be
appropriate now that older policies will no longer support current OLD
setting.

Since the main reason I proposed that was fall back of CMake scripts
that are missing cmake_minimu_required I guess that printing out a
warning for scripts as well would also be fine.

Regards,
Domen
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] A policy for Policies

[Domen Vrankar]

 A better Policy lifecycle would be

 1) Three releases after introducing a Policy, we make OLD the same as WARN
for it. That is, the only way to not get the warning will be to fix the
code or use -Wno-dev.
 2) After some time in years (depending on the impact of the Policy), we
change it to an unconditional error.
 3) Remove the code implementing the OLD behavior in a following release.

+1

 That is because currently Policies *are* feature switches. The answer to
 that is not more warnings, as Alex told us, but error conditions. There
 needs to be credibility to any documentation claiming that setting a Policy
 to OLD will result in an error some day. Such documentatation will be
 ignored.

I've personally never seen them as feature switches but I agree that
they can be too quickly seen as such.

 I've pushed a branch for testing which updates the policies = CMP0011 to
 REQUIRED_IF_USED. Those have resulted in warnings by default for 6 years.
 That is a long time to ignore warnings.

So that's why my newly added test broke with CMP0011 error :) I didn't
even know that I was using this policy with old functionality... Can I
somehow force treating of all policies as errors to spot such cases
for e.g. in tests?

Side question:
Should cmake_minimum_required also be used in CMake scripts (added
with -P argument to CMake command) not just CMakeLists.txt?
And do we really still need version 2.6 as default (we could bump this
version to where current policies are still treated as warnings not
errors)?
I'd also be glad if missing cmake_minimum_required in root CMake
list/script would be treated as error and not as warning since you can
get old policies in by accident.

Regards,
Domen
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [CMake 0011944]: CPackDeb: Support dependencies between components/Debian packages

[Domen Vrankar]

 Please find attached some rework on the documentation. There is no hurry :)

Applied with minor changes:
http://www.cmake.org/gitweb?p=cmake.git;a=commit;h=efab805

Thanks,
Domen
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [CMake 0011944]: CPackDeb: Support dependencies between components/Debian packages

[Domen Vrankar]

 It would have been hard to ship a missing binary in the patch :)

True :)

 Apparently in this package
 https://packages.debian.org/fr/sid/dpkg-dev

 that comes also with build-essential

I actually prefer having one vanilla installation for basic testing so
I'll stick with it.

 BTW, is it the intended behaviour to log message(...) from CPackDeb.cmake
 onto stderr?

That's the default way of printing out with message(...) command so
I'm not certain if that can be changed with mode but since for years
the entire module prints to stderr I'm not certain if changing that
would be a smart thing to do.

 Next I'll take a look at you documentation patch and the comments that
 came along it that mail.


 Many thanks! since it is only one file to merge, I can do that as well.

I won't be working on that until tonight (10-11 pm and I think we're
in the same time zone) so if you'd like you can send a new patch. I've
already merged parts of it with other commits.

Regarding the CPACK_PACKAGE_CONTACT not being used elsewhere - there's
a request for similar functionality in CPackRPM so I intend to use it
there as well. It should stay.

Regards,
Domen
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [CMake 0011944]: CPackDeb: Support dependencies between components/Debian packages

[Domen Vrankar]

I forgot that the previous patch has not yet been merged to master so
no need to hurry.

Thanks,
Domen

2015-05-09 10:58 GMT+02:00, Domen Vrankar domen.vran...@gmail.com:
 It would have been hard to ship a missing binary in the patch :)

 True :)

 Apparently in this package
 https://packages.debian.org/fr/sid/dpkg-dev

 that comes also with build-essential

 I actually prefer having one vanilla installation for basic testing so
 I'll stick with it.

 BTW, is it the intended behaviour to log message(...) from
 CPackDeb.cmake
 onto stderr?

 That's the default way of printing out with message(...) command so
 I'm not certain if that can be changed with mode but since for years
 the entire module prints to stderr I'm not certain if changing that
 would be a smart thing to do.

 Next I'll take a look at you documentation patch and the comments that
 came along it that mail.


 Many thanks! since it is only one file to merge, I can do that as well.

 I won't be working on that until tonight (10-11 pm and I think we're
 in the same time zone) so if you'd like you can send a new patch. I've
 already merged parts of it with other commits.

 Regarding the CPACK_PACKAGE_CONTACT not being used elsewhere - there's
 a request for similar functionality in CPackRPM so I intend to use it
 there as well. It should stay.

 Regards,
 Domen

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [CMake 0011944]: CPackDeb: Support dependencies between components/Debian packages

[Domen Vrankar]

 Please find attached the reworked patch and the fix (separate file) for the
 problem you are facing.
 In separate patches, I also enabled the full debug messages output in a
 separate patch, + some additional logs.

Bitten by my own change... Nice catch. Thanks for finding this.

Your changes did not fix my problem however the changes to logging
made it simple to find what was wrong - missing dpkg-shlibdeps
executable. I'm surprised that it doesn't come along with the vanilla
Debina 7.8.0 installation. Fortunately that revealed this issue.

Applied patches and fixes:
http://www.cmake.org/gitweb?p=cmake.git;a=commit;h=e3f522f

Next I'll take a look at you documentation patch and the comments that
came along it that mail.

Thanks,
Domen
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Missing CPACK_PACKAGE_CONTACT in test for CPackComponentsPrefix

[Domen Vrankar]

2015-05-07 15:12 GMT+02:00 Kornel Benko kor...@lyx.org:
 Hi,
 testing new cmake, I get ctest error for the call
 # ctest -R CPackComponentsPrefix
[snip]

 Adding line
 set(CPACK_PACKAGE_CONTACT someContact)
 in Tests/CPackComponentsPrefix/CMakeLists.txt cures the testcase for me.

Thanks for reporting this.

It would seem that a few CPack tests weren't testing RPM and DEB
packages as variables CPACK_BINARY_DEB and CPACK_BINARY_RPM were
not set.

I'll fix this so that tests will run in nightly testing.

Thanks,
Domen
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Missing CPACK_PACKAGE_CONTACT in test for CPackComponentsPrefix

[Domen Vrankar]

 I'll fix this so that tests will run in nightly testing.

Applied patch:
http://www.cmake.org/gitweb?p=cmake.git;a=commit;h=3f300b

Thanks,
Domen
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [CMake 0011944]: CPackDeb: Support dependencies between components/Debian packages

[Domen Vrankar]

2015-05-04 9:53 GMT+02:00 Domen Vrankar domen.vran...@gmail.com:
 Your test managed to find issues with previous code - automatic
 dependency detection doesn't work on older versions of dpkg-shlibdeps
 script.

 I wrote that a bit unclearly... With previous code I meant code that
 was there already before your patch.


Tests now pass on all test platforms.

Thanks,
Domen
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [CMake 0011944]: CPackDeb: Support dependencies between components/Debian packages

[Domen Vrankar]

/Dev/build/cmake/bin/cpack
131: config_args = 
131: config_verbose = -V
131: -- CPack_output=CPack: Enable Verbose
131: CPack Verbose: Read CPack config file: 
131: CPack Verbose: Read CPack configuration file: 
/home/domen/Dev/build/cmake/Tests/CPackComponentsDEB/buildDEB-components-depend2/CPackConfig.cmake
131: CPack Verbose: Specified generator: DEB
131: CPack Verbose: Use generator: cmCPackDebGenerator
131: CPack Verbose: For project: MyLib
131: CPack: Create package using DEB
131: CPack Verbose: Read description file: 
/media/sf_Dev/projects/cmake/Templates/CPack.GenericDescription.txt
131: CPack Verbose: [DEB] requested component grouping = IGNORE_GROUPS
131: CPack Verbose: Remove toplevel directory: 
/home/domen/Dev/build/cmake/Tests/CPackComponentsDEB/buildDEB-components-depend2/_CPack_Packages/Linux/DEB
131: CPack: Install projects
131: CPack: - Run preinstall target for: CPackComponentsDEB
131: CPack: - Install project: CPackComponentsDEB
131: CPack: -   Install component: applications
131: CPack Verbose: Install configuration: NoConfig
131: CPack Verbose: Installing: 
/home/domen/Dev/build/cmake/Tests/CPackComponentsDEB/buildDEB-components-depend2/_CPack_Packages/Linux/DEB/MyLib-1.0.2-Linux/applications/usr/bin/mylibapp
131: CPack: -   Install component: libraries
131: CPack Verbose: Install configuration: NoConfig
131: CPack Verbose: Installing: 
/home/domen/Dev/build/cmake/Tests/CPackComponentsDEB/buildDEB-components-depend2/_CPack_Packages/Linux/DEB/MyLib-1.0.2-Linux/libraries/usr/lib/libmylib.a
131: CPack: -   Install component: headers
131: CPack Verbose: Install configuration: NoConfig
131: CPack Verbose: Installing: 
/home/domen/Dev/build/cmake/Tests/CPackComponentsDEB/buildDEB-components-depend2/_CPack_Packages/Linux/DEB/MyLib-1.0.2-Linux/headers/usr/include/mylib.h
131: CPack: Create package
131: CPack Verbose: Package files to: 
/home/domen/Dev/build/cmake/Tests/CPackComponentsDEB/buildDEB-components-depend2/_CPack_Packages/Linux/DEB/MyLib-1.0.2-Linux.deb
131: CPack Verbose: Copying final package(s) [3]:
131: CPack: - package: 
/home/domen/Dev/build/cmake/Tests/CPackComponentsDEB/buildDEB-components-depend2/MyLib-1.0.2-Linux-applications.deb
 generated.
131: CPack: - package: 
/home/domen/Dev/build/cmake/Tests/CPackComponentsDEB/buildDEB-components-depend2/MyLib-1.0.2-Linux-headers.deb
 generated.
131: CPack: - package: 
/home/domen/Dev/build/cmake/Tests/CPackComponentsDEB/buildDEB-components-depend2/MyLib-1.0.2-Linux-libraries.deb
 generated.
131: 
131: -- expected_count='3'
131: -- 
expected_file_mask='/home/domen/Dev/build/cmake/Tests/CPackComponentsDEB/buildDEB-components-depend2/MyLib-*.deb'
131: -- 
actual_output_files='/home/domen/Dev/build/cmake/Tests/CPackComponentsDEB/buildDEB-components-depend2/MyLib-1.0.2-Linux-headers.deb;/home/domen/Dev/build/cmake/Tests/CPackComponentsDEB/buildDEB-components-depend2/MyLib-1.0.2-Linux-libraries.deb;/home/domen/Dev/build/cmake/Tests/CPackComponentsDEB/buildDEB-components-depend2/MyLib-1.0.2-Linux-applications.deb'
131: -- actual_count='3'
131: -- package='mylib-headers', dependencies='depend-headers'
131: -- package='mylib-libraries', dependencies='depend-default'
131: -- package='mylib-applications', dependencies=''
131: CMake Error at 
/media/sf_Dev/projects/cmake/Tests/CPackComponentsDEB/RunCPackVerifyResult-components-depend2.cmake:85
 (message):
131:   dpkg-deb checks failed:
131: 
131:   ;dpkg-deb:
131:   
/home/domen/Dev/build/cmake/Tests/CPackComponentsDEB/buildDEB-components-depend2/MyLib-1.0.2-Linux-applications.deb:
131:   Incorrect dependencies for package mylib-applications: '' does not 
contain
131:   any 'lib'
131: 
131: 
131: 
131: 
1/1 Test #131: CPackComponentsDEB-components-depend2 ...***Failed0.39 sec

0% tests passed, 1 tests failed out of 1

Total Test time (real) =   0.40 sec

The following tests FAILED:
131 - CPackComponentsDEB-components-depend2 (Failed)
Errors while running CTest
From b2ce1fcdd4c003f938dd85491a6d181cb24fc00f Mon Sep 17 00:00:00 2001
From: Domen Vrankar domen.vran...@gmail.com
Date: Fri, 8 May 2015 07:51:30 +0200
Subject: [PATCH] CPackDEB: Enabling the settings of the dependencies per
 component.

---
 Modules/CPackDeb.cmake | 48 ++--
 Tests/CMakeLists.txt   |  4 +-
 .../MyLibCPackConfig-components-depend1.cmake.in   | 20 +
 .../MyLibCPackConfig-components-depend2.cmake.in   | 31 
 .../RunCPackVerifyResult-components-depend1.cmake  | 83 +
 .../RunCPackVerifyResult-components-depend2.cmake  | 86 ++
 6 files changed, 264 insertions(+), 8 deletions(-)
 create mode 100644 Tests/CPackComponentsDEB/MyLibCPackConfig-components-depend1.cmake.in
 create mode 100644 Tests/CPackComponentsDEB/MyLibCPackConfig-components-depend2.cmake.in
 create mode 100644 Tests/CPackComponentsDEB/RunCPackVerifyResult-components-depend1.cmake
 create mode 100644 Tests/CPackComponentsDEB

Re: [cmake-developers] [CMake 0011944]: CPackDeb: Support dependencies between components/Debian packages

[Domen Vrankar]

 Thank you Domen! I will send you new patches today or tomorrow for the last
 points.

 BTW, in CDash, where are the builds of next? Is it Nightly Expected or
 Nightly?

Use Nightly Expected. Not certain what Nightly section contains.

Your test managed to find issues with previous code - automatic
dependency detection doesn't work on older versions of dpkg-shlibdeps
script.
https://open.cdash.org/testDetails.php?test=332953264build=3797736
I'll try to get an older version to test on and fix it asap.

Regards,
Domen
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [CMake 0011944]: CPackDeb: Support dependencies between components/Debian packages

[Domen Vrankar]

 Your test managed to find issues with previous code - automatic
 dependency detection doesn't work on older versions of dpkg-shlibdeps
 script.

I wrote that a bit unclearly... With previous code I meant code that
was there already before your patch.

Regards,
Domen
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [PATCH] CPackRPM Module: output RPMBUILDOUT when intended

[Domen Vrankar]

 The following (and attached) patch outputs RPMBUILDERR and RPMBUILDOUT
 as advertised

Applied: http://www.cmake.org/gitweb?p=cmake.git;a=commit;h=1a2a73a

Thanks,
Domen
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [CMake 0011944]: CPackDeb: Support dependencies between components/Debian packages

[Domen Vrankar]

2015-04-29 18:35 GMT+02:00 Domen Vrankar domen.vran...@gmail.com:
 Applied with minor changes
 - added component text from your other patch
 - changed CPACK_DEBIAN_PACKAGE_DESCRIPTION documentation to more
 accurately describe fall back options

 http://www.cmake.org/gitweb?p=cmake.git;a=commit;h=2f0afff

Applied patch 0001-CPackDEB-Enabling-the-dependency-auto-discovery-per-.patch
to next with some changes:
- added slightly modified relevant documentation fixes from your
0001-CPackDeb-reworked-documentation.patch patch
- added dpkg-deb executable check before test

http://www.cmake.org/gitweb?p=cmake.git;a=commit;h=04f4284

Thanks,
Domen
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [CMake 0011944]: CPackDeb: Support dependencies between components/Debian packages

[Domen Vrankar]

 I recommend git rebase:

 https://www.atlassian.com/git/tutorials/rewriting-history/git-rebase-i

Didn't know about interactive mode for rebase - seems allot simpler
than what I described.

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

Re: [cmake-developers] [CMake 0011944]: CPackDeb: Support dependencies between components/Debian packages

[Domen Vrankar]

 Please find attached the patch concerning the description per component,
 with the associated documentation, based on
 75b0e1679c39ca824a4c49d9e1a2ae2b5f04ae06.

Applied with minor changes
- added component text from your other patch
- changed CPACK_DEBIAN_PACKAGE_DESCRIPTION documentation to more
accurately describe fall back options

 I will not move until you validate this patch and merge it to trunk, because
 otherwise I would base work on moving bases. Please note that this is only
 one of the features I need. On my side, I need two additional
 functionalities (shlibdeps + dependency per component).

Patch has to pass nightly builds and then it will most likely be
merged to master (merges to master are not handled by me).

Usually what I do in such cases is
- commit each patch separately to git
- when I have to change one of them I just save commit messages, call
git format-patch -5 HEAD where 5 is the amount of commits to the one
that I wish to change
- use git reset --soft HEAD^ to undo commits
- git checkout * to undo the changes
- change the patch
- commit once again
- reapply other patches with git apply --reject path_to_patch (if
needed search for rej files and apply parts manually)

For small patches this works quite well and is fairly fast - mostly
without reject conflicts. For patches that were not split into smaller
ones this doesn't work so you're back to manual merge...

Thanks,
Domen
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [CMake 0011944]: CPackDeb: Support dependencies between components/Debian packages

[Domen Vrankar]

Hi,

Sorry for not replying sooner.

 Please find attached a patch for the reworked documentation. I tried to make
 the doc more consistent with the CPackRPM (doc right after the variable
 declaration and options afterwards).
 I also put links for the variables and changed the formatting a bit.

Thanks for the patches. You are doing a great work but please start
splitting patches into subpatches... Each patch you provide is a
combination of fixing one thing and adding a bunch of new things to it
as well. Until one patch is added to master that patch is not finished
and should not be built upon with new patches that are remotely
related at best.

If you intend to provide the patches like that then rework the patches
yourself and resubmit all of them each time until they are applied.

 There are a couple of things though:
 - the variable CPACK_PACKAGE_CONTACT does not exist anywhere in the code

I'll take a look after we finish with current patches...

 - right now, the CPACK_COMPONENT_COMP_DESCRIPTION is used as an equivalent
 to the CPACK_DEBIAN_PACKAGE_DESCRIPTION per component. If I follow the RPM
 conventions, those would be called CPACK_DEBIAN_COMP_PACKAGE_DESCRIPTION,
 which I find also better. However, in that case, should it default to
 CPACK_COMPONENT_COMP_DESCRIPTION or to CPACK_DEBIAN_PACKAGE_DESCRIPTION?
 In fact CPACK_COMPONENT_COMP_DESCRIPTION and
 CPACK_DEBIAN_COMP_PACKAGE_DESCRIPTION would have the same purpose and I
 think that it will not be obvious for the user to cope with all those
 variables.

They would not have the same purpose - one is for setting value for
all package generators at once while the other is for debian specific
content.
I am not a fan of generator specific overrides so I haven't bugged you
with that entire hierarchy because it can be added later and because
you volunteered for completely different functionality in the first
place.
On the other hand that is the preferred way of Brad and Eric so I
intended to add the overrides later on.

Regards,
Domen
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [CMake 0011944]: CPackDeb: Support dependencies between components/Debian packages

[Domen Vrankar]

 I am having a look now at the changes you made on the first patch (say
 75b0e1679c39ca824a4c49d9e1a2ae2b5f04ae06), file
 RunCPackComponentsDEB/RunCPackVerifyResult-components-lintian-dpkgdeb-checks.cmake

 Instead of finding lintian and dpkg-deb in the check file
 find_program(LINTIAN_EXECUTABLE lintian)
 find_program(DPKGDEB_EXECUTABLE dpkg-deb)

 why not returning the string NOTFOUND in eg. the functions run_lintian
 lintian_output, like this:

 set(${lintian_output} NOTFOUND PARENT_SCOPE)


One reason is that tests that don't have prerequisites met should not
even be executed in the first place.
The other reason is that if I had time I would rewrite and generalize
all CPack tests to meet those expectations.

Regards,
Domen
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [CMake 0011944]: CPackDeb: Support dependencies between components/Debian packages

[Domen Vrankar]

 Hi,

 Would you please add
 set( CPACK_DEBIAN_PACKAGE_DEBUG ON)

 to the file
 MyLibCPackConfig-splitted-components-depend2.cmake.in

 so that we also have the debug logs?

I currently don't have access to my computer so I'll send you that in
about a week.

 BTW, I do not know what CPackDEB.cmake you are running. Is it pushed
 somehow?

I was using master git branch with all your patches applied so it's
the same code you have.
I just remembered that I did an incremental build an not a fresh one
so I'll have to test if it makes a difference after I get back.

Regards,
Domen
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [CMake 0011944]: CPackDeb: Support dependencies between components/Debian packages

[Domen Vrankar]

 Should I rebased on a2d36e3?

The patch doesn't contain allot of changes so even if you don't the
merge will be trivial so it's up to you.

Regards,
Domen
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [CMake 0011944]: CPackDeb: Support dependencies between components/Debian packages

[Domen Vrankar]

 Thanks for the explanations. Which raises new questions:

 How would I create empty lists then (to which I can subsequently append)? Or
 check that a variable is defined? Or tell the calling function that the
 output variable is set to an empty string?
 Those questions should sound very naive, but this is less than obvious to
 me.

Lists in CMake are strings separated by semicolons
first_element;second_element so empty list is an empty string .

Also you don't even need to create a list variable before appending to
it - first list(APPEND ...) call will create the variable for you.

Testing if(DEFINED) tests if variable actually exists - if it's an
empty string that still means that it exists.

set(var) is the same as unset(var) - in both cases if(DEFINED var)
returns false. So writing set(var) doesn't create an empty string/list
instead it's only a more cryptic way of saying unset(var).

For eg.
set(a ) - defined to empty string
set(b ${a}) - in this case b is undefined
set(c ${a}) - in this case c is an empty string

So if you don't use quotes with set you can get odd errors so it's
better to be consistent.


 For instance

 string(TOUPPER ${CPACK_DEB_PACKAGE_COMPONENT} _local_component_name)
 set(_component_shlibdeps_var
 CPACK_DEBIAN_${_local_component_name}_PACKAGE_SHLIBDEPS)

 if(DEFINED ${_component_shlibdeps_var})
   ...
 The variable _component_shlibdeps_var clearly is defined and contains a
 string that names/points a variable. In the if statement, I am checking if
 the variable pointed by _component_shlibdeps_var is defined by the user. It
 is not clear to me why I would put quotes in this case, there is no risk for
 _component_shlibdeps_var being an empty variable.

 Would it be better with/equivalent to:
 if(${_component_shlibdeps_var})

 ?

No in this case you're right but I prefer using quotes in set()
because of empty string errors - I forget to write them from time to
time but I try to be consistent.


 Another example is
   if(CPACK_DEBIAN_PACKAGE_AUTO_DEPENDS AND NOT
 CPACK_DEBIAN_PACKAGE_AUTO_DEPENDS STREQUAL )

 The intention is to check if CPACK_DEBIAN_PACKAGE_AUTO_DEPENDS is defined
 and is not an empty string. Here I added the 'NOT
 CPACK_DEBIAN_PACKAGE_AUTO_DEPENDS STREQUAL ' to an existing statement. Is
 it equivalent to

 if(NOT ${CPACK_DEBIAN_PACKAGE_AUTO_DEPENDS} STREQUAL )

 ?

Yes it's equivalent.

 Again

 set(CPackRun_CPackDEBConfiguration_ALL_CONFIGS)
 is not the same to me as
 unset(CPackRun_CPackDEBConfiguration_ALL_CONFIGS)

 and actually comes from the line
 set(CPackComponentsForAll_BUILD_OPTIONS)

To cmake they are the same and I had to test that first... I thought
that set(var) meant set(var ) - this was my mistake.


 That is why I mentioned that you aren't using any quotes most of the
 time while using variables.


 When I look at the changes you made,

 set(options )
 set(oneValueArgs FILENAME)

 and from here

 http://www.cmake.org/cmake/help/v3.2/module/CMakeParseArguments.html?highlight=cmake_parse_argument

 I do not see the value of putting the quotes in fact, especially around
 FILENAME, since there are already quotes around ${option}, etc in the call
 to cmake_parse_arguments.

set(options ) was my mistake... Now I know that it should have been
unset(options) or even better delete the variable and its use all
together.
For the FILENAME it's just consistency - using quotes where the text
is a string and doesn't represent a variable name that is used by
list, if and other functions.

Also the reason for mentioning quotes in if statements was that I did
not know that
set(var a b c)
if(${var} STREQUAL a b c)
produces correct result. I expected that it would expand to a list as
it would for set(var a b c).

So in the end other than me having allot more difficulties reviewing
the patch most of the nonquoted variables/values are not important.
The thing is that during a review when I see a non quoted string I
have to go all the way to where it was set and be certain that it
can't be assigned to an empty value, with most of the quotes in place
the review gets allot simpler for me.

 Can it be in a subsequent patch or I should rework those? (reworking the
 patches is more work for me.)

You can create new patches and I'll do the merge.

Thanks,
Domen
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [CMake 0011944]: CPackDeb: Support dependencies between components/Debian packages

[Domen Vrankar]

 Hi,

 I just installed a virtual machine running Debian 7.8.0, and everything
 worked like a charm from the first run. I did that in the two following way:
 - sourced my branch
 https://github.com/raffienficiaud/CMake/tree/cpack_deb_refactoring
 - I also applied the cherry-picked from that branch onto your merge to next
 (8e0ecf91b3d50a0e69a00db52d1d79ca91afecc4).

 The only packages I installed from a default installation are vim,
 build-essential, git, gcc-4.7, cmake, qtcreator, clang.
 Putting the quotes in that case should be safer.

 So I cannot reproduce the error on my side. The log would be helpful.

Odd... I'm not certain what the difference between our virtual
machines is then. As far as I can remember I only additionally
installed gcc and cmake. Maybe some updates...

Attached are the generated files, verbose output and dpkg-deb -I
output for application package.

Thanks,
Domen


CPackComponentsDEB.tgz
Description: GNU Zip 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-developers

Re: [cmake-developers] [CMake 0011944]: CPackDeb: Support dependencies between components/Debian packages

[Domen Vrankar]

 I do not know how you would like to proceed. It should not be any issue in
 applying the patches in sequence from the changes you made yesterday.

Hi,

I just started applying and reviewing the patches. It will take me a
while to get through them. I'll write to you after I'm done.

Thanks,
Domen
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [CMake 0011944]: CPackDeb: Support dependencies between components/Debian packages

[Domen Vrankar]

Hi,

I pushed your first patch to next (I've split it into two separate
commits and made some minor cleanup changes):
http://www.cmake.org/gitweb?p=cmake.git;a=commit;h=8e0ecf9

 Please find attached my last patch that allows the settings of the
 dependencies per component.

I haven't finished reviewing the rest of the patches however I've
noticed that you omit quotes when setting or comparing variables.

I've also noticed that the last test in last commit is succeeding on
Ubuntu 15.04 but failing on Debian 7.8.0.
It first fails with a cryptic error (string FIND requires X variables
as input message...) on this line:
string(FIND ${dpkg_depends} lib index_libwhatever)
and after I put quotes arround ${dpkg_depends} it returns an error
that the value is an empty string.
I haven't researched it further so if you have an option to test it on
Debian that would be great, otherwise I'll provide a fix in the
following days.

Thanks,
Domen
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [CMake 0011944]: CPackDeb: Support dependencies between components/Debian packages

[Domen Vrankar]

 Is there any other thing you would like to do before I continue working on
 this? Do you foresee any other change like this?

No, go ahead.

Regards,
Domen
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [CMake 0011944]: CPackDeb: Support dependencies between components/Debian packages

[Domen Vrankar]

 Hi,

 If I am not mistaken, this does not work in the current state of the
 cmCpackDebGenerator.cxx (I tried of course). I wanted to know by which
 *magic* this could work, and also why you are suggesting me this, which lead
 me to this:

 - CPackRPM: all the RPM creation is driven by the CPackRPM.cmake itself
 - CPackDEB: part of package configuration is sent from the .cmake back to
 the cmCPackDebGenerator.cxx, and some internal functions in C++ are creating
 the package definition.

Sorry about that... I completely forgot about that difference.

 The workflow is not the same, so if I scope all the variables in a function
 in the .cmake file, I have no way to get these variables back in the .cxx
 file. For the RPM package, this is fine since at the end of the
 CPackRPM.cmake call, the package is created.

 My guess is that I do not have the choice: I have to do some set/unset to
 avoid inter-component troubleshooting.

 Any suggestion more than welcome.

The thing is that inside CPack you can only access variables from
project CMakeLists.txt that are prefixed by CPACK_ so CPackDEB can
even see CPACK_RPM* variable settings.

Variables also can't be set across different CPack generators e.g. if
I set a variable inside CPackRPM generator and then run both RPM and
DEB generator at the same time the value won't be present in CPackDEB
generator.

On the other hand variables that are set in CPackDEB.cmake for one
component are later visible in the other - they don't get reread from
CMakeLists.txt for every pass. So setting variables inside
CPackDEB.cmake is a bit dangerous.

For that reason every CPackDEB variable that is used in
cmCPackDebGenerator::createDeb() will have to be renamed for e.g. from
CPACK_DEBIAN_PACKAGE_NAME to something like _CPACK_DEBIAN_PACKAGE_NAME
and in CPackDEB.cmake those variables would have to be set(...
PARENT_SCOPE) from let's say cpack_deb_generate_package() function for
every pass. That way you contain variable setting and prevent future
accidental overwrites.

I'll write a patch for that today and push it to next. I'll also add
link here so that you'll be able to use it before it gets to master.

Regards,
Domen
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [CMake 0011944]: CPackDeb: Support dependencies between components/Debian packages

[Domen Vrankar]

 I'll write a patch for that today and push it to next. I'll also add
 link here so that you'll be able to use it before it gets to master.

Here's the patch: http://www.cmake.org/gitweb?p=cmake.git;a=commitdiff;h=268e008

Now it should be easy to add support for per component variables.
There is an example of per component variables setting in CPackRPM
starting on line 1091: foreach(_RPM_SPEC_HEADER
Maybe something similar could be used in your patch so that adding new
component based variables will be simpler in the future.

I also took another look at your patch and noticed that you per
component variables are using CPACK_DEB_PACKAGE_COMPONENT. Please
convert the value to upper case before using it for per component
variables. This is used for common CPACK_* variables so it would help
with consistency.

Thanks,
Domen
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [CMake 0011944]: CPackDeb: Support dependencies between components/Debian packages

[Domen Vrankar]

 On the other hand variables that are set in CPackDEB.cmake for one
 component are later visible in the other - they don't get reread from
 CMakeLists.txt for every pass. So setting variables inside
 CPackDEB.cmake is a bit dangerous.


 Ok. I do not understand that much the value of this feature, if this is
 intended. For instance, if I would like to make something available to all
 components (eg. some transformation of the name for instance), I would do
 this implementation in the .cxx file by running the loop on all components
 and populating an internal variable of the .cxx file. I would avoid anything
 that depends on the sequence of the components seen by the CPackDeb.cmake.

I'm not certain either... It was implemented like that when I took
over the maintenance of CPackRPM and CPackDEB half a year or so ago.

As far as I know with RPM the decision was made that most of the
functionality should be in cmake script so that eventually there would
be no need for generator specific C++ code - easier to extend/modify
functionality for the end users if they need to.

Both approaches have their strengths and weaknesses
- RPM with most of the logic in cmake script and relying on native rpm
tools and configuration.
- DEB with relying on C++ code and creating package without the need
of deb tools.
But for now I'm not trying to change their basic design.

 On the other hand, the risks might be limited if, by /convention/, we say
 that all _cpack_deb_local_*** variables are reserved for local use only,
 initialized at the beginning of the CPackDeb.cmake (or before).

Such agreements have the limitation of being forgotten so I prefer
enforcing it in code with a single base function in cmake script :)


 For that reason every CPackDEB variable that is used in
 cmCPackDebGenerator::createDeb() will have to be renamed for e.g. from
 CPACK_DEBIAN_PACKAGE_NAME to something like _CPACK_DEBIAN_PACKAGE_NAME
 and in CPackDEB.cmake those variables would have to be set(...
 PARENT_SCOPE) from let's say cpack_deb_generate_package() function for
 every pass. That way you contain variable setting and prevent future
 accidental overwrites.

 I'll write a patch for that today and push it to next. I'll also add
 link here so that you'll be able to use it before it gets to master.


 Sounds like a bunch of conflicts on my side :)
 Go ahead.

Sorry about that :( It's just that I noticed that in the past there
were many attempts at preventing accidental leakage of variables in
CPackRPM and I don't want to get the same problem in CPackDEB so it's
better to prevent it asap.

Regards,
Domen
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [CMake 0011944]: CPackDeb: Support dependencies between components/Debian packages

[Domen Vrankar]

 I was wondering if this issue has been addressed so far.

As far as I can tell from the bug report I don't think so... If it
doesn't work in CMake 3.2 then it definitely wasn't.

 If the maintainer of the CPackDeb agrees, I can try to resolve this.

Go ahead.
Could you also provide some automated test cases for this?

Thanks,
Domen
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [CMake 0011944]: CPackDeb: Support dependencies between components/Debian packages

[Domen Vrankar]

 I confirm this does not work with 3.2. I also would like to disable
 CPACK_DEBIAN_PACKAGE_SHLIBDEPS on some of the components (dpkg-shlibdeps
 complains right now for eg. packages containing only documentation).

Fine with me as long as you provide the tests.

 Ok, it was a good excercise to start with.

 In the member function cmCPackGenerator::WantsComponentInstallation,
 apparently it is required that groups AND components exist to have the
 component install:
 https://github.com/Kitware/CMake/blob/master/Source/CPack/cmCPackGenerator.cxx#L1505

 If I change the line to
  (!(this-ComponentGroups.empty()) || !(this-Components.empty(

 it works as before (cmake 2.8.12).

 Is it required that groups and components are defined to be able to have a
 component installation? (one file per component). In the wiki page,
 http://www.cmake.org/Wiki/CMake:Component_Install_With_CPack

This was my patch that handles the case of only one component. Somehow
managed to simplify the line too much...
RunCMake.CPackRPM tests this feature implicitly - creates a rpm
package even though only one component is present.

Do you have git permissions to push this patch? You can also send the
patch and I'll commit the fix.

Thanks,
Domen
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [CMake 0011944]: CPackDeb: Support dependencies between components/Debian packages

[Domen Vrankar]

 In the member function cmCPackGenerator::WantsComponentInstallation,
 apparently it is required that groups AND components exist to have the
 component install:
 https://github.com/Kitware/CMake/blob/master/Source/CPack/cmCPackGenerator.cxx#L1505

 If I change the line to
  (!(this-ComponentGroups.empty()) || !(this-Components.empty(

 it works as before (cmake 2.8.12).

I've pushed the patch with minor changes to next.
http://www.cmake.org/gitweb?p=cmake.git;h=0779b679

Thanks,
Domen
-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] new cpack tests

[Domen Vrankar]

Hi all,

In the past few months some additional semantic checks were added into
CPackComponentsForAll test - in particularly into IgnoreGroup test.

Now it's becoming harder to add new tests there as each test requires
somewhat different package content and variable settings. It is also
getting harder to see which part of package creation is actually
required for which package validation at the end.

Because of the reasons above there are less CPackRPM tests than I'd
like to see so I've decided to create new tests for testing CPack.

The requirements that I know of are:
1) Each test should provide its own recipe on how to create packages
(the way it is done for executing CMake in RunCMake tests - with cmake
script for each test)

2) Each test should provide a verify results script that terminates
with FATAL_ERROR message on failure (maybe also printing out actual
output and for RPM also generated spec file or some other relevant
data for fixing tests that fail on nightly build servers) - this
script differs from regex and return code tests in RunCMake as it has
to execute different package query commands (or maybe unpack a
generated archive) to get the result for comparison

3) Running the tests should first execute CMake, then CPack and at the
end verify the result (first two steps are covered in
RunCMake.CPackRPM test)

4) Tests should be listed as in RunCMake RunCMakeTest.cmake scripts

5) Each test should also specify for which CPack generators should a
test be executed (this would require one verify result script per
generator per test)

6) Each test should also specify a list of expected generated files
(and maybe intermediate files as RPM spec files) for automatic
validation of expected output

This would be most useful for RPM and DEB packages validation,
somewhat useful for archive generators and less useful for NSIS and
other GUI installer generators (not sure how to test those other than
check that installer file was generated...).

I've managed to add CPackRPM test to RunCMake even though it requires
first execution of CMake and afterwards also execution of CPack but
I'm not certain that trying to squeeze the tests described above into
RunCMake is the right way to go.

So now I have two questions...

Would it be OK if I add something like CPackSemanticTests (I'm bad
with names) into Tests directory and implement it similarly to
RunCMake tests?

Does anybody have additional ideas on how to extend/improve the list
of requirements written above (e.g. with steps to validate GUI
installer packages or simplify the tests so that there would be less
work involved in adding new ones)?

Thanks,
Domen
-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] file glob and glob recurse directory listing difference

[Domen Vrankar]

Hi all,

I'm working on a patch to enable directory listing in
file(GLOB_RECURSE...). Currently GLOB lists directories and
GLOB_RECURSE doesn't.

I was thinking about unifying the two by providing
NO_DIRECTORY_LISTING option. Unfortunately this breaks back
compatibility so I would need to use a policy.

My question is may I use/define the next available policy number for that?

Alternative would be to define LIST_DIRECTORIES for GLOB_RECURSE only
and preserve back compatibility that way - maybe also define
NO_DIRECTORY_LISTING for GLOB just for the sake of consistency.

Thanks,
Domen
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [PATCH] CPack: change cpack_set_if_not_set into a function

[Domen Vrankar]

 If you work on that, please include tests (perhaps in the form of a
 new Tests/RunCMake/CPack directory), documentation updates, and a
 release note in a file such as 'Help/release/dev/cpack-maybe-set.rst'.

For that you could rename Tests/RunCMake/CPackRPM to CPack  and add
your tests there - CMakeLists.txt and RunCMakeTest.cmake files should
be what you need.

Regards,
Domen
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] KWSys patches

[Domen Vrankar]

 FYI, the proposed GetCanonicalPath already exists in KWSys as
 SystemTools::GetRealPath.  It returns the unchanged path on error.
 That could be extended to take an optional second argument as a
 pointer to a buffer describing the error.  If the argument is NULL
 use the current behavior.  Otherwise return an empty string and
 populate the error info.  Then make your new call sites use the
 new argument.

Hm I missed this one... My old nightly version Code::Blocks seems to
have missed it in search. Thanks.

Attached are patches for KWSys Glob and SystemTools (with changes
required by Glob).

Thanks,
Domen
From 88566a6912e795b435be585a7bf009ba40d1f73c Mon Sep 17 00:00:00 2001
From: Domen Vrankar domen.vran...@gmail.com
Date: Sat, 21 Feb 2015 10:54:34 +0100
Subject: [PATCH 1/4] glob recurse cyclic recursion handling

Prevent cyclic recursion of type a/b/c-a when
glob recurse is used with follow symlinks so
that each directory symbolic link is traversed
only once and skipped on revisit.
---
 Source/kwsys/Glob.cxx   | 81 -
 Source/kwsys/Glob.hxx.in| 36 --
 Source/kwsys/SystemTools.cxx| 59 +++---
 Source/kwsys/SystemTools.hxx.in |  7 +++-
 4 files changed, 161 insertions(+), 22 deletions(-)

diff --git a/Source/kwsys/Glob.cxx b/Source/kwsys/Glob.cxx
index 5a96aed..43da52f 100644
--- a/Source/kwsys/Glob.cxx
+++ b/Source/kwsys/Glob.cxx
@@ -19,6 +19,7 @@
 #include KWSYS_HEADER(Directory.hxx)
 #include KWSYS_HEADER(stl/string)
 #include KWSYS_HEADER(stl/vector)
+#include KWSYS_HEADER(stl/algorithm)
 
 // Work-around CMake dependency scanning limitation.  This must
 // duplicate the above list of headers.
@@ -30,6 +31,8 @@
 # include SystemTools.hxx.in
 # include kwsys_stl.hxx.in
 # include kwsys_stl_string.hxx.in
+# include kwsys_stl_vector.hxx.in
+# include kwsys_stl_algorithm.hxx.in
 #endif
 
 #include ctype.h
@@ -214,13 +217,13 @@ kwsys_stl::string Glob::PatternToRegex(const kwsys_stl::string pattern,
 }
 
 //
-void Glob::RecurseDirectory(kwsys_stl::string::size_type start,
-  const kwsys_stl::string dir)
+bool Glob::RecurseDirectory(kwsys_stl::string::size_type start,
+  const kwsys_stl::string dir, GlobMessages* messages)
 {
   kwsys::Directory d;
   if ( !d.Load(dir) )
 {
-return;
+return true;
 }
   unsigned long cc;
   kwsys_stl::string fullname;
@@ -265,8 +268,64 @@ void Glob::RecurseDirectory(kwsys_stl::string::size_type start,
   if (isSymLink)
 {
 ++this-FollowedSymlinkCount;
+kwsys_stl::string realPathErrorMessage;
+kwsys_stl::string canonicalPath(SystemTools::GetRealPath(dir,
+realPathErrorMessage));
+
+if(!realPathErrorMessage.empty())
+  {
+  if(messages)
+{
+messages-push_back(Message(
+Glob::error, Canonical path generation from path '
++ dir + ' failed! Reason: ' + realPathErrorMessage + '));
+}
+  return false;
+  }
+
+if(kwsys_stl::find(VisitedSymlinks.begin(), VisitedSymlinks.end(),
+  canonicalPath) == VisitedSymlinks.end())
+  {
+  struct ScopedSymlinkPath
+  {
+ScopedSymlinkPath(
+  kwsys_stl::vectorkwsys_stl::string visitedSymlinks,
+  const std::string canonicalPath)
+  : RefVisitedSymlinks(visitedSymlinks)
+  {
+  RefVisitedSymlinks.push_back(canonicalPath);
+  }
+~ScopedSymlinkPath() {RefVisitedSymlinks.pop_back();}
+kwsys_stl::vectorkwsys_stl::string RefVisitedSymlinks;
+  } scopedSymlinkPath(VisitedSymlinks, canonicalPath);
+
+  if(!this-RecurseDirectory(start+1, realname, messages))
+{
+return false;
+}
+  }
+// else we have already visited this symlink - prevent cyclic recursion
+else if(messages)
+  {
+  kwsys_stl::vectorkwsys_stl::string::const_iterator pathIt =
+  kwsys_stl::find(VisitedSymlinks.begin(), VisitedSymlinks.end(),
+canonicalPath);
+  kwsys_stl::string message;
+  for(pathIt; pathIt != VisitedSymlinks.end(); ++pathIt)
+{
+message += *pathIt + \n;
+}
+  message += canonicalPath + / + fname;
+  messages-push_back(Message(Glob::cyclicRecursion, message));
+  }
+}
+  else
+{
+if(!this-RecurseDirectory(start+1, realname, messages))
+  {
+  return false;
+  }
 }
-  this-RecurseDirectory(start+1, realname);
   }
 else
   {
@@ -277,17 +336,19 @@ void Glob::RecurseDirectory(kwsys_stl::string::size_type start,
 }
   }
 }
+
+  return true

Re: [cmake-developers] [PATCH 0/3] CPACK_RPM_PACKAGE_ARCHITECTURE

[Domen Vrankar]

2015-02-19 9:01 GMT+01:00 Joshua A Clayton stillcompil...@gmail.com:
 This patch series extends CPackRPM to support cross-built rpms
 Previously only native and noarch rpms were possible.
 Other architecture choices resulted in an error from rpmbuild.
 Also included at no extra charge, is component support through
 CPACK_RPM_component_PACKAGE_ARCHITECTURE, and unit tests for
 component architecture.

Applied with minor tweaks to next:
http://www.cmake.org/gitweb?p=cmake.git;a=commitdiff;h=43fab4ca

Thanks,
Domen
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] KWSys patches

[Domen Vrankar]

 Attached are patches for KWSys Glob and SystemTools (with changes
 required by Glob).

I apologize for spamming...

After rewriting CMake tests with directories instead of symlinks I
noticed that patch 3 was not handling basic directory case.

Attached are patches with fixed patch 3.

Thanks,
Domen
From 88566a6912e795b435be585a7bf009ba40d1f73c Mon Sep 17 00:00:00 2001
From: Domen Vrankar domen.vran...@gmail.com
Date: Sat, 21 Feb 2015 10:54:34 +0100
Subject: [PATCH 1/4] glob recurse cyclic recursion handling

Prevent cyclic recursion of type a/b/c-a when
glob recurse is used with follow symlinks so
that each directory symbolic link is traversed
only once and skipped on revisit.
---
 Source/kwsys/Glob.cxx   | 81 -
 Source/kwsys/Glob.hxx.in| 36 --
 Source/kwsys/SystemTools.cxx| 59 +++---
 Source/kwsys/SystemTools.hxx.in |  7 +++-
 4 files changed, 161 insertions(+), 22 deletions(-)

diff --git a/Source/kwsys/Glob.cxx b/Source/kwsys/Glob.cxx
index 5a96aed..43da52f 100644
--- a/Source/kwsys/Glob.cxx
+++ b/Source/kwsys/Glob.cxx
@@ -19,6 +19,7 @@
 #include KWSYS_HEADER(Directory.hxx)
 #include KWSYS_HEADER(stl/string)
 #include KWSYS_HEADER(stl/vector)
+#include KWSYS_HEADER(stl/algorithm)
 
 // Work-around CMake dependency scanning limitation.  This must
 // duplicate the above list of headers.
@@ -30,6 +31,8 @@
 # include SystemTools.hxx.in
 # include kwsys_stl.hxx.in
 # include kwsys_stl_string.hxx.in
+# include kwsys_stl_vector.hxx.in
+# include kwsys_stl_algorithm.hxx.in
 #endif
 
 #include ctype.h
@@ -214,13 +217,13 @@ kwsys_stl::string Glob::PatternToRegex(const kwsys_stl::string pattern,
 }
 
 //
-void Glob::RecurseDirectory(kwsys_stl::string::size_type start,
-  const kwsys_stl::string dir)
+bool Glob::RecurseDirectory(kwsys_stl::string::size_type start,
+  const kwsys_stl::string dir, GlobMessages* messages)
 {
   kwsys::Directory d;
   if ( !d.Load(dir) )
 {
-return;
+return true;
 }
   unsigned long cc;
   kwsys_stl::string fullname;
@@ -265,8 +268,64 @@ void Glob::RecurseDirectory(kwsys_stl::string::size_type start,
   if (isSymLink)
 {
 ++this-FollowedSymlinkCount;
+kwsys_stl::string realPathErrorMessage;
+kwsys_stl::string canonicalPath(SystemTools::GetRealPath(dir,
+realPathErrorMessage));
+
+if(!realPathErrorMessage.empty())
+  {
+  if(messages)
+{
+messages-push_back(Message(
+Glob::error, Canonical path generation from path '
++ dir + ' failed! Reason: ' + realPathErrorMessage + '));
+}
+  return false;
+  }
+
+if(kwsys_stl::find(VisitedSymlinks.begin(), VisitedSymlinks.end(),
+  canonicalPath) == VisitedSymlinks.end())
+  {
+  struct ScopedSymlinkPath
+  {
+ScopedSymlinkPath(
+  kwsys_stl::vectorkwsys_stl::string visitedSymlinks,
+  const std::string canonicalPath)
+  : RefVisitedSymlinks(visitedSymlinks)
+  {
+  RefVisitedSymlinks.push_back(canonicalPath);
+  }
+~ScopedSymlinkPath() {RefVisitedSymlinks.pop_back();}
+kwsys_stl::vectorkwsys_stl::string RefVisitedSymlinks;
+  } scopedSymlinkPath(VisitedSymlinks, canonicalPath);
+
+  if(!this-RecurseDirectory(start+1, realname, messages))
+{
+return false;
+}
+  }
+// else we have already visited this symlink - prevent cyclic recursion
+else if(messages)
+  {
+  kwsys_stl::vectorkwsys_stl::string::const_iterator pathIt =
+  kwsys_stl::find(VisitedSymlinks.begin(), VisitedSymlinks.end(),
+canonicalPath);
+  kwsys_stl::string message;
+  for(pathIt; pathIt != VisitedSymlinks.end(); ++pathIt)
+{
+message += *pathIt + \n;
+}
+  message += canonicalPath + / + fname;
+  messages-push_back(Message(Glob::cyclicRecursion, message));
+  }
+}
+  else
+{
+if(!this-RecurseDirectory(start+1, realname, messages))
+  {
+  return false;
+  }
 }
-  this-RecurseDirectory(start+1, realname);
   }
 else
   {
@@ -277,17 +336,19 @@ void Glob::RecurseDirectory(kwsys_stl::string::size_type start,
 }
   }
 }
+
+  return true;
 }
 
 //
 void Glob::ProcessDirectory(kwsys_stl::string::size_type start,
-  const kwsys_stl::string dir)
+  const kwsys_stl::string dir, GlobMessages* messages)
 {
   //kwsys_ios::cout  ProcessDirectory:   dir  kwsys_ios::endl;
   bool last = ( start == this-Internals-Expressions.size()-1 );
   if ( last

Re: [cmake-developers] KWSys patches

[Domen Vrankar]

 I'll get the KWSys patch through.  Once it is integrated into
 CMake then you can rebase the CMake part of the change on that.

 However, please revise the logic in the KWSys patch to avoid
 using exceptions.

I've noticed that exceptions are not used but was not certain how else
to handle this (and CMake at least printed out the error message
before exiting - did not know that this is common code for different
projects at the time).

I have a few ideas but they all seem semi optimal to me so I'll need
some guidance regarding this...

One option would be to return empty string from
Directory::GetCanonicalPath if an error occurs but currently when
Glob::FindFiles returns false error checking in CMake code treats it
as if no files were found so I don't think that returning false would
be the way to go.

Other option would be to call exit() inside the
Directory::GetCanonicalPath function but I guess that this would be
even worse than throwing an exception...

Third option that came to mid was to return empty string
Directory::GetCanonicalPath if an error occurs and simply ignore it in
Glob class - since the error should occur only rarely/never and
circular recursion is a corner case this is probably the best
solution...

One more question... When I first started writing the patch I thought
about printing out a warning if circular recursion is detected but was
not certain if it would be OK to just write the output to std::cerr
(or the kwsys wrapper equivalent) with canonical paths that caused it.
Should I leave out such message or would it be better to add it and
how?

Thanks,
Domen
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [PATCH] CPackRPM: Fix cross-building rpms

[Domen Vrankar]

 I've finally had some time to read over the Tests section, and it is a
 bit overwhelming.
 I'm going to describe the use cases for my patch and perhaps you can
 give me some guidance on adding an actual test.

 There are three, maybe four use cases:
 1) native rpm (e.g. x86_64)
 2) noarch rpm (a noarch package should contain scripts, artwork, etc,
 but no compiled code)
 3) a non-native, but compatible rpm (e.g. building x86 on a multilib
 x86_64 system)
 4) incompatible cross-compiled package (e.g. building for arm or ppc)

 in each case the way you know it worked is
 a) make package successfully produces an rpm file
 b) running rpm -qip my_rpm_file.my_arch.rpm returns a description of the rpm,
  including the line Architecture: my_arch

Sorry for the late reply.

I've finally had some time to go through the patch:
1) If I understand you correctly BuildArch should never be set except
in noarch case. This would mean that CPACK_RPM_PACKAGE_ARCHITECTURE
value should set --target and if set to noarch should also (if
necessary) set BuildArch as before. Your patch currently silently
ignores all user settings of CPACK_RPM_PACKAGE_ARCHITECTURE except
noarch,
2) Since you are already writing a patch for
CPACK_RPM_PACKAGE_ARCHITECTURE you should also add
CPACK_RPM_component_PACKAGE_ARCHITECTURE so that you can set the
architecture per component.

Regarding the tests:
1) You should add the test setup for noarch and auto defined and auto
detected architecture in
Tests/CPackComponentsForAll/MyLibCPackConfig-IgnoreGroup.cmake.in -
just define architecture for headers component (implement 2. from
above for this) and leave the rest of components to auto detection
provided by your patch,
2) Write result verification in
Tests/CPackComponentsForAll/RunCPackVerifyResult.cmake - just extend
the tests at the bottom of this file since pqy query is already used
there.

I am not certain regarding where to put cross-compiled package test...
If rpmbuild is not testing the binaries that will get packed you can
simply set a nonexisting XYZ architecture to only one component - like
with noarch.

Regards,
Domen
-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] KWSys patches

[Domen Vrankar]

Hi everyone,

I am having problems with a patch for Glob functionality because Glob
is part of KWSys repository.

I tried to register to http://review.source.kitware.com so that I
would be able to commit patches to KWSys repository but after I put in
my OpenID I got a Not Found error.

How can I contribute this patch?

Attached are KWSys patch and KWSys+CMake patch.

Thanks,
Domen
From 9c113fe546669a064d461004ae7e74be07744e40 Mon Sep 17 00:00:00 2001
From: Domen Vrankar domen.vran...@gmail.com
Date: Sun, 15 Feb 2015 20:42:16 +0100
Subject: [PATCH] handle cyclic recursion when using glob recurse with follow
 symlinks

Prevent cyclic recursion of type a/b/c-a when
glob recurse is used with follow symlinks so
that each directory symbolic link is traversed
only once and skipped on revisit.
---
 Source/kwsys/Directory.cxx | 35 ++
 Source/kwsys/Directory.hxx.in  |  7 +
 Source/kwsys/Glob.cxx  | 32 +++-
 Source/kwsys/Glob.hxx.in   |  2 ++
 .../file/GLOB_RECURSE-symlink-recursion-stderr.txt |  2 ++
 .../file/GLOB_RECURSE-symlink-recursion.cmake  | 10 +++
 Tests/RunCMake/file/RunCMakeTest.cmake |  1 +
 7 files changed, 88 insertions(+), 1 deletion(-)
 create mode 100644 Tests/RunCMake/file/GLOB_RECURSE-symlink-recursion-stderr.txt
 create mode 100644 Tests/RunCMake/file/GLOB_RECURSE-symlink-recursion.cmake

diff --git a/Source/kwsys/Directory.cxx b/Source/kwsys/Directory.cxx
index 58cea63..5494908 100644
--- a/Source/kwsys/Directory.cxx
+++ b/Source/kwsys/Directory.cxx
@@ -18,6 +18,7 @@
 
 #include KWSYS_HEADER(stl/string)
 #include KWSYS_HEADER(stl/vector)
+#include KWSYS_HEADER(stl/stdexcept)
 
 // Work-around CMake dependency scanning limitation.  This must
 // duplicate the above list of headers.
@@ -28,8 +29,11 @@
 # include kwsys_stl.hxx.in
 # include kwsys_stl_string.hxx.in
 # include kwsys_stl_vector.hxx.in
+# include kwsys_stl_stdexcept.hxx.in
 #endif
 
+#include stdlib.h
+
 namespace KWSYS_NAMESPACE
 {
 
@@ -79,6 +83,37 @@ const char* Directory::GetPath() const
 }
 
 //
+kwsys_stl::string Directory::GetCanonicalPath() const
+{
+/* The maximum length of a file name. */
+#if defined(PATH_MAX)
+  #define CANONICAL_PATH_MAX_LEN PATH_MAX
+#elif defined(MAXPATHLEN)
+  #define CANONICAL_PATH_MAX_LEN MAXPATHLEN
+#else
+  #define CANONICAL_PATH_MAX_LEN 16384
+#endif
+
+  char out_path[CANONICAL_PATH_MAX_LEN];
+
+#if defined(_WIN32)  !defined(__CYGWIN__)
+  /* Implementation for Windows.  */
+  DWORD n = GetFullPathNameA(this-Internal-Path.c_str(),
+  CANONICAL_PATH_MAX_LEN], out_path, 0);
+  if( n  0  n = CANONICAL_PATH_MAX_LEN )
+#else
+  /* Implementation for UNIX.  */
+  if( !realpath(this-Internal-Path.c_str(), out_path) )
+#endif
+{
+throw kwsys_stl::runtime_error(Failed to convert path '
+  + this-Internal-Path + ' to canonical form.);
+}
+
+  return out_path;
+}
+
+//
 void Directory::Clear()
 {
   this-Internal-Path.resize(0);
diff --git a/Source/kwsys/Directory.hxx.in b/Source/kwsys/Directory.hxx.in
index 1bcf90e..453b578 100644
--- a/Source/kwsys/Directory.hxx.in
+++ b/Source/kwsys/Directory.hxx.in
@@ -68,6 +68,13 @@ public:
   const char* GetPath() const;
 
   /**
+   * Return path to Open'ed directory without symbolic links, dot or
+   * dot-dot elements. runtime_error is thrown if canonical path
+   * could not be created.
+   */
+   kwsys_stl::string GetCanonicalPath() const;
+
+  /**
* Clear the internal structure. Used internally at beginning of Load(...)
* to clear the cache.
*/
diff --git a/Source/kwsys/Glob.cxx b/Source/kwsys/Glob.cxx
index 5a96aed..22bab9f 100644
--- a/Source/kwsys/Glob.cxx
+++ b/Source/kwsys/Glob.cxx
@@ -30,11 +30,14 @@
 # include SystemTools.hxx.in
 # include kwsys_stl.hxx.in
 # include kwsys_stl_string.hxx.in
+# include kwsys_stl_vector.hxx.in
 #endif
 
 #include ctype.h
 #include stdio.h
 #include string.h
+#include stdlib.h
+#include iostream
 namespace KWSYS_NAMESPACE
 {
 #if defined(_WIN32) || defined(__APPLE__) || defined(__CYGWIN__)
@@ -265,8 +268,35 @@ void Glob::RecurseDirectory(kwsys_stl::string::size_type start,
   if (isSymLink)
 {
 ++this-FollowedSymlinkCount;
+kwsys_stl::string canonicalPath(d.GetCanonicalPath());
+
+if(VisitedSymlinks.find(canonicalPath) == VisitedSymlinks.end())
+  {
+  // structure for handling symbolic link path even if an exception
+  // is thrown
+  struct ScopedSymlinkPath
+  {
+ScopedSymlinkPath(
+  kwsys_stl::setkwsys_stl::string visitedSymlinks,
+  const std::string canonicalPath)
+  : RefVisitedSymlinks(visitedSymlinks)
+  , RefCanonicalPath(canonicalPath

Re: [cmake-developers] old policies interfering with script provided by CPack

[Domen Vrankar]

 I decided not to add a module-wide policy scope just before a release
 in case it causes other problems.  Instead I converted the fix to set
 the policy locally:

  CPackRPM: Do not run file(GLOB_RECURSE) without CMP0009 set to NEW
  http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=be36bfd6

 Please verify this still works for the original problem.

Patch fixes the problem.

Thanks,
Domen
-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] old policies interfering with script provided by CPack

[Domen Vrankar]

Hi everyone,

During testing of CPackRPM with older CMakeLists.txt I noticed that
cmake_minimum_required from that script affects how CPackRPM script
works.

The policy that is causing problems is CMP0009 - FILE GLOB_RECURSE
calls should not follow symlinks by default.

To get around this problem I thought about wrapping the entire script with:

cmake_policy(PUSH)
cmake_policy(VERSION 3.1)
cmake_policy(POP)

Would this be an acceptable solution?
Does anybody have a better idea?

Thanks,
Domen
-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] fixing a bug after topic was merged to master

[Domen Vrankar]

Hi all,

While writing tests for a new topic I found a bug in an older topic
that I wrote.
The that topic was already merged to master (last week) but remote
stage branch still exists.
The fix is trivial - one variable typo.

How can I get the fix both into master and next release candidate branch?
Should I create a new topic and push that to next or should I extend
the old one even though it was already merged to master and push that
one to next?

Thanks,
Domen
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [PATCH] CPackRPM: Fix cross-building rpms

[Domen Vrankar]

 Add the --target argument to rpmbuild
 Do not add a BuildArch variable to the spec file for arch specific packages
 BuildArch causes rpm building to fail except for noarch packages

I'm not too familiar with cross compilation problems so could you
please also provide a simple test case to help with patch review?

Thanks,
Domen
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [PATCH][CPack][RPM] multiple path relocation prefixes

[Domen Vrankar]

 Most of the RunCMake tests are for negative tests, but mostly for
 running cmake.  IIUC you need tests that run cpack, right?
 For that you can use run_cmake_command.  See use in the
 RunCMake.CTestMemcheck test to run ctest:

  Tests/RunCMake/CTestMemcheck/RunCMakeTest.cmake

 See also Tests/RunCMake/CommandLine/RunCMakeTest.cmake for other
 uses to try the non-generator signatures of cmake.

 The topic as of commit 36f93b60 has Tests/CPackRPM/RunCPack.cmake
 which should be refactored to use RunCMake infrastructure, perhaps
 in a new Tests/RunCMake/CPackRPM test.  Please extend the topic
 to move the test over.

Attached is the patch for this. Please apply it.

I'm unable to apply it myself as git push to stage is reporting
conflicts and git pull from stage is reporting not a repository
error...

Thanks,
Domen
From 5368d2e2aa880f42fd1e3593c4ea7f14855bb60e Mon Sep 17 00:00:00 2001
From: Domen Vrankar domen.vran...@gmail.com
Date: Wed, 28 Jan 2015 23:48:57 +0100
Subject: [PATCH] fixup! cpack rpm multiple path relocation prefixes

CPackRPM test was refactored to use RunCMake infrastructure.
---
 Tests/CMakeLists.txt|  9 -
 Tests/CPackRPM/CMakeLists.txt   | 14 --
 Tests/CPackRPM/RunCPack.cmake   | 21 -
 Tests/RunCMake/CMakeLists.txt   |  4 
 Tests/RunCMake/CPackRPM/CMakeLists.txt  |  7 +++
 ...PackRPM_PARTIALLY_RELOCATABLE_WARNING-stderr.txt |  1 +
 .../CPackRPM_PARTIALLY_RELOCATABLE_WARNING.cmake|  7 +++
 Tests/RunCMake/CPackRPM/RunCMakeTest.cmake  | 17 +
 8 files changed, 36 insertions(+), 44 deletions(-)
 delete mode 100644 Tests/CPackRPM/CMakeLists.txt
 delete mode 100644 Tests/CPackRPM/RunCPack.cmake
 create mode 100644 Tests/RunCMake/CPackRPM/CMakeLists.txt
 create mode 100644 Tests/RunCMake/CPackRPM/CPackRPM_PARTIALLY_RELOCATABLE_WARNING-stderr.txt
 create mode 100644 Tests/RunCMake/CPackRPM/CPackRPM_PARTIALLY_RELOCATABLE_WARNING.cmake
 create mode 100644 Tests/RunCMake/CPackRPM/RunCMakeTest.cmake

diff --git a/Tests/CMakeLists.txt b/Tests/CMakeLists.txt
index 007f735..dea30e4 100644
--- a/Tests/CMakeLists.txt
+++ b/Tests/CMakeLists.txt
@@ -832,15 +832,6 @@ ${CMake_BINARY_DIR}/bin/cmake -DDIR=dev -P ${CMake_SOURCE_DIR}/Utilities/Release
   # Do not try to build RPM
   if (NOT RPMBUILD)
 set(CPACK_BINARY_RPM OFF)
-  else()
-add_test(CPack-RPM ${CMAKE_CMAKE_COMMAND}
--D dir=${CMake_BINARY_DIR}/Tests/CPackRPM
--D CMake_SOURCE_DIR=${CMake_SOURCE_DIR}
--D CMAKE_CMAKE_COMMAND=${CMAKE_CMAKE_COMMAND}
--P ${CMake_SOURCE_DIR}/Tests/CPackRPM/RunCPack.cmake
-  )
-list(APPEND TEST_BUILD_DIRS
-  ${CMake_BINARY_DIR}/Tests/CPackRPM)
   endif()
 
   find_program(NSIS_MAKENSIS_EXECUTABLE NAMES makensis
diff --git a/Tests/CPackRPM/CMakeLists.txt b/Tests/CPackRPM/CMakeLists.txt
deleted file mode 100644
index 968f6d6..000
--- a/Tests/CPackRPM/CMakeLists.txt
+++ /dev/null
@@ -1,14 +0,0 @@
-cmake_minimum_required(VERSION 3.1 FATAL_ERROR)
-
-project(CPackRPM)
-
-install(FILES CMakeLists.txt DESTINATION /not_relocatable COMPONENT static)
-install(FILES CMakeLists.txt DESTINATION relocatable COMPONENT relocatable)
-
-set(CPACK_PACKAGE_RELOCATABLE TRUE)
-set(CPACK_GENERATOR RPM)
-set(CPACK_PACKAGING_INSTALL_PREFIX /opt)
-
-set(CPACK_RPM_COMPONENT_INSTALL ON)
-
-include(CPack)
diff --git a/Tests/CPackRPM/RunCPack.cmake b/Tests/CPackRPM/RunCPack.cmake
deleted file mode 100644
index 8bef611..000
--- a/Tests/CPackRPM/RunCPack.cmake
+++ /dev/null
@@ -1,21 +0,0 @@
-cmake_minimum_required(VERSION 3.1 FATAL_ERROR)
-
-file(MAKE_DIRECTORY ${dir})
-
-# run cmake
-execute_process(
-  COMMAND ${CMAKE_CMAKE_COMMAND} ${CMake_SOURCE_DIR}/Tests/CPackRPM
-  WORKING_DIRECTORY ${dir}
-  OUTPUT_QUIET)
-
-# package RPM
-execute_process(
-  COMMAND make package
-  WORKING_DIRECTORY ${dir}
-  ERROR_VARIABLE stderr
-  OUTPUT_QUIET)
-
-# test for partial relocation warning
-if(NOT ${stderr} MATCHES CPackRPM:Warning: Path /not_relocatable/CMakeLists.txt is not on one of the.*relocatable paths! Package will be partially relocatable.)
-  message(FATAL_ERROR CPack/RPM missing partially relocatable warning; stderr output: '${stderr}')
-endif()
diff --git a/Tests/RunCMake/CMakeLists.txt b/Tests/RunCMake/CMakeLists.txt
index b5e41d9..15a24de 100644
--- a/Tests/RunCMake/CMakeLists.txt
+++ b/Tests/RunCMake/CMakeLists.txt
@@ -173,3 +173,7 @@ add_RunCMake_test(CommandLine)
 add_RunCMake_test(install)
 add_RunCMake_test(CPackInstallProperties)
 add_RunCMake_test(ExternalProject)
+
+if(RPMBUILD)
+  add_RunCMake_test(CPackRPM)
+endif()
diff --git a/Tests/RunCMake/CPackRPM/CMakeLists.txt b/Tests/RunCMake/CPackRPM/CMakeLists.txt
new file mode 100644
index 000..b7d170b
--- /dev/null
+++ b/Tests/RunCMake/CPackRPM/CMakeLists.txt
@@ -0,0 +1,7 @@
+cmake_minimum_required(VERSION 3.1 FATAL_ERROR)
+
+project(${RunCMake_TEST} NONE

[cmake-developers] CPack RPM failing tests on dashboard

[Domen Vrankar]

I've noticed CPack/RPM test fails on dashboard for two
Fedora-19-x86_64 machines:

https://open.cdash.org/buildSummary.php?buildid=3658687
https://open.cdash.org/buildSummary.php?buildid=3658677

Would it be possible to get generated rpm files from one of them for analysis?

/home/kevin/kitware/CMake_Build/Tests/CPackComponentsForAll/buildRPM-IgnoreGroup/MyLib-1.0.2-Linux-Unspecified.rpm
/home/kevin/kitware/CMake_Build/Tests/CPackComponentsForAll/buildRPM-IgnoreGroup/MyLib-1.0.2-Linux-applications.rpm
/home/kevin/kitware/CMake_Build/Tests/CPackComponentsForAll/buildRPM-IgnoreGroup/MyLib-1.0.2-Linux-headers.rpm
/home/kevin/kitware/CMake_Build/Tests/CPackComponentsForAll/buildRPM-IgnoreGroup/MyLib-1.0.2-Linux-libraries.rpm

Thanks,
Domen
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] CPack RPM failing tests on dashboard

[Domen Vrankar]

 May be you can make  RunCPackVerifyResult.cmake more verbose when a
 failure occurs?
 (i.e. a bunch of extra rpm query on the culprit generated RPM) and/or more
 informations
 in the error message.

You're right. Haven't thought about such cases when I don't have the
output RPM files. I'll extend the logging.

Thanks,
Domen
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [PATCH] Setting default user, group and permissions for CPackRPM

[Domen Vrankar]

 On 01/13/2015 01:55 AM, Domen Vrankar wrote:
 This patch is somewhat related to
 http://public.kitware.com/pipermail/cmake/2014-December/059460.html
 (bug report: http://www.cmake.org/Bug/view.php?id=3602) as it defines
 user and group that should be used for RPM content but on a per RPM
 scale since it is not possible to define it in install command.

The provided patch is only somewhat related because it sets default
permissions, user and group on a global scale and can be overwritten
per file by install command. Currently all files are by default
installed through rpm as root:root (provided patch would at least add
global override option for this).

 If it were possible to define it in the install() command, that would
 be useful for local installs.  We would also need the information to
 be communicated to the packaging step.  If such functionality existed,
 would it eliminate the need for a CPack/RPM-specific solution?

The functionality described above is a workaround for cases when
CPack/RPM doesn't support some file manipulation that RPM spec files
support so the functionality would stay in place for the time being
but for setting user and group it would no longer be needed.

Currently you have to write something like this:

install(...) # command used to install file - this should be the only
requirement
set(CPACK_RPM_USER_FILELIST %attr(-,usrname,groupname)
/opt/some_file) # set something like this for each file individually
(making CMakeLists.txt less readable, CPack/RPM generator specific and
more error prone)

 Should the staged install location for packaging not bother setting uid/gid
 because they will be handled by the packaging tool instead?
 We need to be able to package on a host machine that does not have the users
 or groups of the target machine (perhaps because a pre-install script
 in the package creates the users/groups).

I'm not certain about other CPack generators but for RPM user and
group don't need to exist as rpm packaging tool only sets user and
group without actually changing them - they are only actually set on
files during rpm installation.
RPM spec file requires user and group name and not uid/gid exactly
because on install environment the ids will probably differ from
packaging environment. That is why uid and gid in install command
don't help much - if CPack/RPM would use uid and gid from install
command it would be limited to users and groups listed in systems
/etc/passwd file.

I could write an initial patch for bug report 3602 that would add user
and group setting to install command and add that functionality to
CPack/RPM and later we could extend the use for install and other
CPack generators to use it as well (I also wrote some ideas for a
patch here http://www.cmake.org/pipermail/cmake/2015-January/059518.html).

 My question is if such functionality would be useful for other CPack
 packagers as well?

 I would think so.  The permissions are a property of the project and
 target environment, not of the packaging tools.  Each CPack generator
 should treat permissions according to the capabilities of its tools
 and target environment.

In this case I will add the defaults to be set to CPACK_ variables and
later the variables can be used by other CPack generators.

Regards,
Domen
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [PATCH][CPack][RPM] multiple path relocation prefixes

[Domen Vrankar]

2014-12-31 2:03 GMT+01:00 Domen Vrankar domen.vran...@gmail.com:
 Hello,

 Could somebody please review the topic rpm_multi_prefix.

 http://www.cmake.org/gitweb?p=stage/cmake.git;a=commit;h=c908ba3707fcf8cf43df0c5cd90f8ea6d98d7c29

 Patch adds support for multiple relocation paths per RPM package.
 For relocation paths I have extended GNUInstallDirs module since it
 already provides the required functionality but for install command.
 Is this OK?

 Thanks,
 Domen

This topic is now on stage branch for quite a while and since there
were no objections regarding extension of GNUInstallDirs module I'd
like to merge it to next.

Are there any specifics when merging topic from stage to next after it
has been on stage for a while?

Thanks,
Domen
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [PATCH][CPack][RPM] multiple path relocation prefixes

[Domen Vrankar]

Resending as I accidentally dropped the developers mailing list...

2015-01-16 22:38 GMT+01:00 Brad King brad.k...@kitware.com:
 On 01/16/2015 08:42 AM, Brad King wrote:
 Go ahead and merge to 'next' for testing and follow up with any
 dashboard trouble.  I'll still be able to review it there.

 AFAICT the change to GNUInstallDirs is just to help projects use
 the new feature, and not actually part of the new feature itself.
 The feature itself just happens to use the same set of dir values.

Yes I added variables to GNUInstallDirs as a convenience method. Users
can still choose to set values without the use of GNUInstallDirs
module.

 It feels a bit strange to have CPACK_ variables set by GNUInstallDirs,
 and to require CPACK_PACKAGING_INSTALL_PREFIX to be set before that
 module is included.

 Perhaps instead CPackRPM can provide an option to compute a default
 for CPACK_PACKAGING_INSTALL_FULL_dir based on the GNUInstallDirs
 values.  This way GNUInstallDirs does not have to change at all,
 and users can choose to include GNUInstallDirs and still set their
 own CPACK_PACKAGING_INSTALL_FULL_dir values separately.

I tried to do that first but the problem is that only CPACK_*
variables are propagated to CPackRPM script and I thought that
redefining the variables with new names in GNUInstallDirs is better
than creating a new module just for that.

I could write a new module for converting CMAKE_INSTALL* variables to
CPACK_PACKAGING_INSTALL* variables and then generate
CPACK_PACKAGING_INSTALL_FULL_
dir inside CPackRPM.

Alternative that comes to mind is that I just remove the convenience
method of setting variables through GNUInstallDirs.

I'm opened to suggestions.

 +  set(TMP_RPM_PREFIXES ${TMP_RPM_PREFIXES} PARENT_SCOPE)

 Typically I quote the second argument in this case.  It is not
 strictly necessary but looks cleaner IMO.

I agree.

 Please look at adding test cases, perhaps in Tests/RunCMake,
 to check the warning message about non-relocatable paths.

Haven't tried to write negative tests or parsing of command line
during test execution. Are there any good examples of such tests?

 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][CPack][RPM] multiple path relocation prefixes

[Domen Vrankar]

2015-01-16 23:16 GMT+01:00 Domen Vrankar domen.vran...@gmail.com:
 One other idea came to mind... Allow arbitrary paths for different
 prefixes and a script to generate prefixes from paths in
 GNUInstallDirs. That would be a more general solution.

 I could also remove the use of GNUInstallDirs paths all together but I
 like the idea of having packaging relocation paths set automatically
 by defining install paths since that guarantees the consistency of the
 structure installed by cmake and from rpm...

I've decided to go with the generic solution and without dependency on
GNUInstallDirs altogether.

Thanks for the review Brad.

Regards,
Domen
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [PATCH][CPack][RPM] multiple path relocation prefixes

[Domen Vrankar]

 I'm not familiar with the corresponding use case.  Please explain
 how multiple relocation paths works in general with RPM tools.

In RPM packages you can specify multiple Prefix: sections and during
installation you have multiple options:

use --prefix new_path during installation: this will take the
value of first Prefix: path from spec file and relocate all the
paths from old path to provided path (I'd say that this is a back
compatibility feature of RPM) - for this reason I have preserved first
Prefix: path in spec file to be the same as in
CPACK_PACKAGING_INSTALL_PREFIX variable (same as before the patch) in
situations where this path is really used (with the patch
CPACK_PACKAGING_INSTALL_PREFIX would probably be set to / in most
cases).

use --relocate path_from_spec_file=new_path (this flag may be
repeated multiple times): Prefix: path from spec file that matches
the one provided by relocate flag will be replaced by new path and
this enables us to move for e.g. only documentation or libraries - we
are no longer bound to one root location for all files in a single
relocatable RPM.

http://rpm5.org/docs/api/relocatable.html

e.g.
-

spec file:
Prefix: /foo
Prefix: /foo/bin
Prefix: /foo/share/lib

/foo/bin/some_program
/foo/lib/some_lib
/foo/share/lib/some_other_lib
/bar/not_relocatable

rpm installation:
rpm -i --relocate /foo/bin=/bar/bin --relocate /foo/share/lib=/foo/lib
rpm_file

This will relocate some_program and some_other_lib during install but
will keep some_lib on the same location as defined in spec file.

rpm installation option 2:
rpm -i --prefix /foo/share rpm_file

This will relocate all three files to /foo/share/bin/some_program,
/foo/share/lib/some_lib and /foo/share/share/lib/some_other_lib

In both cases not_relocatable file will not be relocated since its
path prefix was not defined in spec file as relocatable.

-

I've checked and this feature is provided in RPM 3.0.5 on AIX as well
as in 4.12 on latest Fedora (version 21) so the feature is not just
RPM5 fork specific.

I've bound the relocation paths to standard GNU filesystem locations
and since GNUInstallDirs.cmake module already provides this
functionality for install command I extended that module. I don't know
who the maintainer of the module is so I hope that extending it in
such way is OK.

Thanks,
Domen
-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] [PATCH] Setting default user, group and permissions for CPackRPM

[Domen Vrankar]

Hi all,

I wrote a patch for http://www.cmake.org/Bug/view.php?id=14714 which
add support for defining RPM package default user, group, file
permissions and directory permissions (default file and dir
permissions accept the same values that are defined for install
command PERMISSIONS without SETUID and SETGID).

This patch is somewhat related to
http://public.kitware.com/pipermail/cmake/2014-December/059460.html
(bug report: http://www.cmake.org/Bug/view.php?id=3602) as it defines
user and group that should be used for RPM content but on a per RPM
scale since it is not possible to define it in install command.

My question is if such functionality would be useful for other CPack
packagers as well?

If yes for default user and group I would suggest adding the following
variables to CPack and the attached patch:
CPACK_DEFAULT_USER and CPACK_compName_DEFAULT_USER for default user setting
CPACK_DEFAULT_GROUP and CPACK_compName_DEFAULT_GROUP for default group setting
and if there would also be interest in default permissions also:
CPACK_DEFAULT_FILE_PERMISSIONS and
CPACK_compName_DEFAULT_FILE_PERMISSIONS for default file permissions
and
CPACK_DEFAULT_DIR_PERMISSIONS and
CPACK_compName_DEFAULT_DIR_PERMISSIONS for default directory permissions

Regards,
Domen
From 8a7981b4e710cbcf730eb30f16fc205992cf68d2 Mon Sep 17 00:00:00 2001
From: Domen Vrankar domen.vran...@gmail.com
Date: Tue, 13 Jan 2015 00:22:02 +0100
Subject: [PATCH] cpack rpm setting of defattr

RPM supports setting of default user, group,
file and directory permissions that will be
applied for files in package unless specified
per file/dir with attr setting
---
 Modules/CPackRPM.cmake | 125 -
 .../MyLibCPackConfig-IgnoreGroup.cmake.in  |  11 ++
 .../RunCPackVerifyResult.cmake |  25 +
 3 files changed, 160 insertions(+), 1 deletion(-)

diff --git a/Modules/CPackRPM.cmake b/Modules/CPackRPM.cmake
index d2cb2ee..a2a3be0 100644
--- a/Modules/CPackRPM.cmake
+++ b/Modules/CPackRPM.cmake
@@ -379,6 +379,54 @@
 #
 #  May be used to add more exclude path (directories or files) from the initial
 #  default list of excluded paths. See CPACK_RPM_EXCLUDE_FROM_AUTO_FILELIST.
+#
+# .. variable:: CPACK_RPM_DEFAULT_USER
+#   CPACK_RPM_compName_DEFAULT_USER
+#
+#  default user ownership of RPM content
+#
+#  * Mandatory : NO
+#  * Default   : root
+#
+#  Value should be user name and not UID.
+#  Note that compName must be in upper-case.
+#
+# .. variable:: CPACK_RPM_DEFAULT_GROUP
+#   CPACK_RPM_compName_DEFAULT_GROUP
+#
+#  default group ownership of RPM content
+#
+#  * Mandatory : NO
+#  * Default   : root
+#
+#  Value should be group name and not GID.
+#  Note that compName must be in upper-case.
+#
+# .. variable:: CPACK_RPM_DEFAULT_FILE_PERMISSIONS
+#   CPACK_RPM_compName_DEFAULT_FILE_PERMISSIONS
+#
+#  default permissions used for packaged files
+#
+#  * Mandatory : NO
+#  * Default   : - (system default)
+#
+#  Accepted values are lists with PERMISSIONS. Valid permissions
+#  are OWNER_READ, OWNER_WRITE, OWNER_EXECUTE, GROUP_READ,
+#  GROUP_WRITE, GROUP_EXECUTE, WORLD_READ, WORLD_WRITE and WORLD_EXECUTE.
+#  Note that compName must be in upper-case.
+#
+# .. variable:: CPACK_RPM_DEFAULT_DIR_PERMISSIONS
+#   CPACK_RPM_compName_DEFAULT_DIR_PERMISSIONS
+#
+#  default permissions used for packaged directories
+#
+#  * Mandatory : NO
+#  * Default   : - (system default)
+#
+#  Accepted values are lists with PERMISSIONS. Valid permissions
+#  are OWNER_READ, OWNER_WRITE, OWNER_EXECUTE, GROUP_READ,
+#  GROUP_WRITE, GROUP_EXECUTE, WORLD_READ, WORLD_WRITE and WORLD_EXECUTE.
+#  Note that compName must be in upper-case.
 
 #=
 # Copyright 2007-2009 Kitware, Inc.
@@ -395,6 +443,51 @@
 
 # Author: Eric Noulard with the help of Alexander Neundorf.
 
+function(get_unix_permissions_octal_notation PERMISSIONS_VAR RETURN_VAR)
+  set(PERMISSIONS ${${PERMISSIONS_VAR}})
+  list(LENGTH PERMISSIONS PERM_LEN_PRE)
+  list(REMOVE_DUPLICATES PERMISSIONS)
+  list(LENGTH PERMISSIONS PERM_LEN_POST)
+
+  if(${PERM_LEN_PRE} EQUAL ${PERM_LEN_POST})
+set(OWNER_PERMISSIONS 0)
+set(GROUP_PERMISSIONS 0)
+set(WORLD_PERMISSIONS 0)
+
+foreach(PERMISSION ${PERMISSIONS})
+  if(${PERMISSION} STREQUAL OWNER_READ)
+math(EXPR OWNER_PERMISSIONS ${OWNER_PERMISSIONS} + 4)
+  elseif(${PERMISSION} STREQUAL OWNER_WRITE)
+math(EXPR OWNER_PERMISSIONS ${OWNER_PERMISSIONS} + 2)
+  elseif(${PERMISSION} STREQUAL OWNER_EXECUTE)
+math(EXPR OWNER_PERMISSIONS ${OWNER_PERMISSIONS} + 1)
+  elseif(${PERMISSION} STREQUAL GROUP_READ)
+math(EXPR GROUP_PERMISSIONS ${GROUP_PERMISSIONS} + 4)
+  elseif(${PERMISSION} STREQUAL GROUP_WRITE)
+math(EXPR GROUP_PERMISSIONS ${GROUP_PERMISSIONS} + 2)
+  elseif(${PERMISSION} STREQUAL GROUP_EXECUTE)
+math

[cmake-developers] [PATCH][CPack][RPM] multiple path relocation prefixes

[Domen Vrankar]

Hello,

Could somebody please review the topic rpm_multi_prefix.

http://www.cmake.org/gitweb?p=stage/cmake.git;a=commit;h=c908ba3707fcf8cf43df0c5cd90f8ea6d98d7c29

Patch adds support for multiple relocation paths per RPM package.
For relocation paths I have extended GNUInstallDirs module since it
already provides the required functionality but for install command.
Is this OK?

Thanks,
Domen
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [PATCH] Avoid bad alloc for large files

[Domen Vrankar]

 I received a bad alloc when uploading a large file with CTest. The patch
 below resolved this.

 Your patch is line-wrapped and can't be applied. However, I did this by hand.
 This is basically the same, but it avoids the needless floating point
 arithmetic. Does it work for you?

snip

  std::string cmCTest::Base64EncodeFile(std::string file)

snip

 -static_castdouble(len) * 1.5 + 5.0) ];
 += new unsigned char [ (len * 3) / 2 + 5 ];

snip

I came across a similar issue a few days ago in our code base (bad
alloc when compressing a large file in-memory with 256 MB data ulimit
per process) and I used a different formula to calculate the maximum
buffer size:

http://stackoverflow.com/questions/1533113/calculate-the-size-to-a-base-64-encoded-message

I used a bit modified answer from kanaka.

size_t output_size = ((len - 1) / 3) * 4 + 4;
size_t final_size = output_size + (output_size / 64) * 2; // 64
instead of 76 since RFC 3548 and RFC 4648 allow CLRF line breaks every
64 characters

This formula would give less memory allocation overhead.

Regards,
Domen
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [PATCH] Avoid bad alloc for large files

[Domen Vrankar]

 I received a bad alloc when uploading a large file with CTest. The patch
 below resolved this.

I just took a look at the code and noticed that it is quite memory
consumption heavy ((2 * encoded_buffer_size) + file_buffer_size).
This implementation could be used instead (not tested):

std::string cmCTest::Base64EncodeFile(const std::string file)
{
  const size_t len = cmSystemTools::FileLength(file);
  cmsys::ifstream ifs(file.c_str(), std::ios::in
#ifdef _WIN32
| std::ios::binary
#endif
);
  std::string base64; // set to empty string by default

  // section for throwing encoded_buffer out of scope as soon as possible to
  // use up less memory
  {
const size_t output_size = ((len - 1) / 3) * 4 + 4;
const size_t final_size = output_size + (output_size / 64) * 2;
std::vectorunsigned char encoded_buffer;
encoded_buffer.resize(final_size);

// section for throwing file_buffer out of scope as soon as possible to
// use up less memory
{
  std::vectorunsigned char file_buffer;
  file_buffer.resize(len);
  ifs.read(reinterpret_castchar*(file_buffer), len);
  ifs.close();

  unsigned long rlen
= cmsysBase64_Encode(file_buffer[0], len, encoded_buffer[0], 1);
}

// consume less memory by swapping tmp string buffer with base64 variable
std::string(encoded_buffer.begin(), encoded_buffer.begin() +
rlen).swap(base64);
  }

  return base64; // this will produce another copy in C++98
}

It lowers memory consumption to approximately (2 *
encoded_buffer_size) and it also makes memory deallocation exception
safe (file_buffer and encoded_buffer variables).
A better solution would be to rewrite the function to:
void cmCTest::Base64EncodeFile(const std::string file, std::string
base64) to prevent one more copy at return but since this changes the
interface we could go a step further and simply rewrite the entire
function and cmsysBase64_Encode function to use streams and thereby
lower the memory consumption even further (less copying between
different containers and more readable than the above version).

Thoughts?

p.s. I think that using std::ios::binary would work on all platforms
so I guess that the function does not need ifdef at the top.

Regards,
Domen
-- 

Powered by www.kitware.com

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

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

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

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

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