Re: [cmake-developers] CPackComponentsDEB-components-depend2 test fails

[Raffi Enficiaud]

On 04.07.19 23:55, Rolf Eike Beer wrote:
> Am Donnerstag, 4. Juli 2019, 23:33:22 CEST schrieb Rolf Eike Beer:
>> Raffi Enficiaud wrote:
>>> [...]
>>> is not creating a shared library by default on this distribution or is
>>> interacting with other options you may have passed?
>>> What if you explicitly write those lines like this:
>>>
>>> add_library(mylib SHARED mylib.cpp)
> 
> I have looked into the library deb file: in case it is a static library it 
> contains /usr/lib64/libmylib.a, in case of a shared library it only contains 
> an empty /usr.
> 

Thanks for the feedback. What if now you replace "ARCHIVE" by "LIBRARY"
in the same file, in the following command?

install(TARGETS mylib
  ARCHIVE
  DESTINATION ${CMAKE_INSTALL_LIBDIR}
  COMPONENT libraries)

If this fixes the issue, I'll file a PR.
Thanks,
Raffi



signature.asc
Description: OpenPGP digital signature
-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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] CPackComponentsDEB-components-depend2 test fails

[Raffi Enficiaud]

On 04.07.19 12:59, Rolf Eike Beer wrote:
> I have a Gentoo and an openSUSE system, that both have various dpkg* tools 
> installed for $reasons.
>
> I know that I need to disable the CPackDEB tests, they create a dynamic 
> executable and check the deb afterwards. Since this is no Debian like system 
> the libc this links to is not covered by any dep.
Hi,

I wrote those tests quite some time ago. They are basically checking if
CPackDEB is handling the options that were passed to it properly.
> When running the CPackComponentsDEB-components-depend2 test I get this output:
> [...]
>
> Is this the same reason and I should just filter this test out (in contrast 
> to 
> the other CPackComponentsDEB tests, which work fine), do we need some sort 
> of automatic detection, or what?
This failure indicates that:

- the default CPACK_DEBIAN_PACKAGE_SHLIBDEPS is on: it activates the
automatic detection of the dependencies with shlibdeps. This is a Debian
tool.
- for all components but the application one, the shlibdeps is disabled
- the application component should inherit from the default one
- since the application points to the shared library, then it should
have this dependency while it does not according to shlibdeps.

Here the test assumes that there is a shared library the application
component links to.

I do not know much about Gentoo. Maybe the line

-- Tests/CPackComponentsDEB/CMakeLists.txt:13

# Create the mylib library
add_library(mylib mylib.cpp)

---

is not creating a shared library by default on this distribution or is
interacting with other options you may have passed?
What if you explicitly write those lines like this:

add_library(mylib SHARED mylib.cpp)

Best,
Raffi
-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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] Shared library under Windows and CMake: DLL not found before installation

[Raffi Enficiaud]

On 06.02.19 19:46, Joachim Wuttke wrote:
> 
>
> Works under Linux, stable since many years. Under Windows10 though, a
> message window
> pops up, entitled "mytest.exe - System error": "The code execution
> cannot proceed
> because mylib.dll was not found. Reinstalling the program may fix this
> problem."
>
> No, installing (rather than reinstalling) would not be a good
> solution: I need to
> first test the library before I install it (btw: this excludes most
> solutions
> proposed in response to somewhat similar questions).
>
> Isn't CMake supposed to work cross-platform? What is the minimally
> invasive adjustment
> to make the above build steps work under Windows?
>
> Disclosure: this is a cross-posting from
> https://stackoverflow.com/questions/54560434.
But I believe this is rather a question for the cmake-user mailing list.

So I replied on SO :)

Raffi

-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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] Labels on tests defined on another subdirectory

[Raffi Enficiaud]

On 19.09.18 08:25, Marc CHEVRIER wrote:
directory property 'TESTS' returns the tests created in the 
*current* directory only.
The main reason to this limitation is the fact that tests created in 
different directories can have same name.


The get_directory_property call is made from the directory that is 
calling add_subdirectory, so I am guessing that the property is 
available everywhere?


I would like to modify the labels of some specific tests. Is there a 
non-intrusive way to do that? Can I set a variable to inherit this LABEL 
before the call to add_subdirectory?


Thanks!
Raffi




Le mer. 19 sept. 2018 à 02:22, Raffi Enficiaud 
<mailto:raffi.enfici...@mines-paris.org>> a écrit :


Hi,

I just wanted to know if it is possible from a directory to add labels
on tests defined on a sub-directory (via add_subdirectory).

When I do a set_tests_properties on the tests that were retrieved with
get_directory_property, cmake says that the test is not found.

Maybe I am missing some syntax there? The following does not work:

get_directory_property(CURRENT_DIRECTORY_TESTS
                                   DIRECTORY ${my_dir}
                                   TESTS)

if(NOT "${CURRENT_DIRECTORY_TESTS}" STREQUAL "")
      set_tests_properties(${CURRENT_DIRECTORY_TESTS} PROPERTIES LABELS
"some-labels")
endif()


Thanks!
Raffi

-- 


Powered by www.kitware.com <http://www.kitware.com>

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

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

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

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

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






--

Powered by www.kitware.com

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

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

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

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

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

[CMake] Labels on tests defined on another subdirectory

[Raffi Enficiaud]

Hi,

I just wanted to know if it is possible from a directory to add labels 
on tests defined on a sub-directory (via add_subdirectory).


When I do a set_tests_properties on the tests that were retrieved with 
get_directory_property, cmake says that the test is not found.


Maybe I am missing some syntax there? The following does not work:

get_directory_property(CURRENT_DIRECTORY_TESTS
 DIRECTORY ${my_dir}
 TESTS)

if(NOT "${CURRENT_DIRECTORY_TESTS}" STREQUAL "")
set_tests_properties(${CURRENT_DIRECTORY_TESTS} PROPERTIES LABELS 
"some-labels")

endif()


Thanks!
Raffi

--

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] CMake 3.12.0-rc1 is ready for testing

[Raffi Enficiaud]

Le 26/06/2018 à 17:18, Brad King a écrit :

On 06/25/2018 01:56 PM, Raffi Enficiaud wrote:

would it be possible to add the following to the release notes?

* FindMatlab now supports the Matlab Runtime Compiler (MCR) for
compiling and linking matlab extensions. The MCR does not
consume any license and is free to download.


Added here:

   https://gitlab.kitware.com/cmake/cmake/merge_requests/2173

We should have done that as part of the original work:

   https://gitlab.kitware.com/cmake/cmake/merge_requests/1970

-Brad



I am sorry I forgot. Thank you!

Raffi

--

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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] [ANNOUNCE] CMake 3.12.0-rc1 is ready for testing

[Raffi Enficiaud]

Le 14/06/2018 à 21:10, Robert Maynard a écrit :
I am proud to announce the first CMake 3.12 release candidate. 
https://cmake.org/download/


Documentation is available at: https://cmake.org/cmake/help/v3.12

Release notes appear below and are also published at 
https://cmake.org/cmake/help/v3.12/release/3.12.html


Some of the more significant changes in CMake 3.12 are:

[snip]

* The "FindCURL" module now provides imported targets.

* The "FindJPEG" module now provides imported targets.

* A "FindODBC" module was added to find an Open Database Connectivity
(ODBC) library.

* New "FindPython3" and "FindPython2" modules, as well as a new 
"FindPython" module, have been added to provide a new way to locate 
python environments.




Hi!

would it be possible to add the following to the release notes?

* FindMatlab now supports the Matlab Runtime Compiler (MCR) for
  compiling and linking matlab extensions. The MCR does not
  consume any license and is free to download.

Thanks!
Raffi

--

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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] Tools for handling cross project dependencies

[Raffi Enficiaud]

Le 02.10.17 à 18:06, Egor Pugin a écrit :

Sorry, maybe I did not understand you correctly, but why do you need
some order of 'add_subdirectory'?


I am not sure to understand why you are asking this, please let me know 
if I am off-topic :)


I have say libOpenCV, libTIFF and libZ. libTIFF depends on libZ, 
libOpenCV depends on libTIFF and libZ.


libTIFF and libZ are doing some magic, say they compile from source or 
if those libraries are available from the OS, they just include the 
system libraries as imported targets.


In a project, I would like to link to libOpenCV, I know it depends on 
libTIFF and libZ, but I do not know if there is any dependencies between 
those libTIFF and libZ.


I know that I should do an add_subdirectory(libOpenCV) and before that, 
do an add_subdirectory of libTIFF and libZ. Depending on the orders of 
the add_subdirectory, I would be able to compile or not libTIFF and 
subsequently libOpenCV.


This should work:

"""""
add_subdirectory(libZ)
add_subdirectory(libTIFF)
add_subdirectory(libOpenCV)
"""""

and this should not work
"""""
add_subdirectory(libTIFF)
add_subdirectory(libZ)
add_subdirectory(libOpenCV)
"""""

(because the declaration of the libTIFF targets make implicit reference 
to headers and shared/static library of libZ.)


So in a "superproject" (the one that is making the 3 calls to 
add_subdirectory above), there is an implicit orchestration/ordering of 
the add_subdirectory commands, and I would somehow like to encode this 
within CMake and without any other tool.


Of course, in this very naive and simplified example, it is easy to 
address, but this does not scale up efficiently. Somehow, there is a 
need to encode the graph of dependencies, and to inject that graph into 
CMake.


This is what I suggest to do: discuss about the interest and the 
"protocol" for encoding such a graph, and what type of information which 
should carry in the graph (nodes and arrows).



Cppan knows from config (yaml) files what deps must be included and
just adds them one by one. If they're already in the tree, include
guard prevents second use.


Right, but there is also an explicit order in your YAML files, isn't it? 
I have to say I have not look very deeply.



One rule is not to have cyclic deps.


Yes, the dependencies should form a Directed Acyclic Graph, otherwise we 
have troubles. This can be checked also very easily.




In summary (correct me if I am wrong) what this does is (in some pseudo code):


Correct pseudo code for cppan:
---
if (TARGET t1)
  return

include(d1) # include file has i. guard
include(d2) # cannot use add_subdirectory directly
...

declare t1
target_deps t1 d1 d2 ...
---


Also in a more complicated settings, you can certainly have the targets 
defined by
d1/d2 sourced by another CMakeLists.txt (say libZ used for target 
t1=OpenCV and target

t2=libYAML, those being on different CMakeLists.txt).

You address this by adding an include guard.
As a matter of facts, include guards are inducing a topological sort on 
the order
of the targets declaration (roughly speaking "include guards=an 
implementation of topological sort").


Having access to the dependency graph is however providing a richer 
information and ease

of maintenance, and I am pretty sure this can find many different use cases
(outside of mine of course).

For example:

* being agnostic to the overall directory layout: in your example you 
only care about the
  targets d1/d2 being declared, not the file/location of their 
declaration (while the include

  directive enforces some directory layout)
* detect cyclic dependencies
* easy filtering of include or add_subdirectory calls, based on the 
selection of specific
  targets (only the direct and indirect parents of the selected target 
are included in the project,

  which is easy to do if we have access to the dependency graph)
* generated installation package dependency declaration (the debian 
packages extract the

  direct dependencies from this graph)
* etc...

I hope I clarified better the problems I am trying to address,

Best,
Raffi


On 2 October 2017 at 16:10, Raffi Enficiaud
<raffi.enfici...@mines-paris.org> wrote:

Le 27.09.17 à 19:10, Egor Pugin a écrit :


The idea is to include several "packages" (one package ~ one project in
Boost) and make those available to the build, exactly as for a regular
CMakeLists.txt that adds several directories or subprojects through a
sequence of calls to "add_directories".
However, the difference here is that "packages" have inter-dependencies,
and the order of the "add_directories" should honor those dependencies.



I solved the issue of including several dirs (via 'add_directories')
using guards 'if (TARGET name); return(); endif()' in my pkg manager.
See boost libraries there: https://cppan.org/search?q=boost

Re: [cmake-developers] Tools for handling cross project dependencies

[Raffi Enficiaud]

Le 27.09.17 à 19:10, Egor Pugin a écrit :

The idea is to include several "packages" (one package ~ one project in Boost) and make 
those available to the build, exactly as for a regular CMakeLists.txt that adds several directories 
or subprojects through a sequence of calls to "add_directories".
However, the difference here is that "packages" have inter-dependencies, and the order of 
the "add_directories" should honor those dependencies.


I solved the issue of including several dirs (via 'add_directories')
using guards 'if (TARGET name); return(); endif()' in my pkg manager.
See boost libraries there: https://cppan.org/search?q=boost
Each library can be included to project separately with autoincluding
required deps for it.


Hi,

Thank you for your answer. What you did with CPAN is wonderful, but I 
think this much more than what my humble scripts are trying to address.


Also the guard mechanism does not really address the issue of ordering 
the add_directories in some topological order. In particular, you guard 
because you do not want to declare several times the same target, but it 
does not tell when to include any other dependencies your target may have.


In summary (correct me if I am wrong) what this does is (in some pseudo 
code):


-
if(target1, target2 ... already defined)
  return

declare target1, target2 ...
target_dependencies target1, target1.1, target1.2 ...
target_dependencies target2, target2.1, target2.2 ...
-

but it does not tell when to declare target1.1, target1.2 ... and this 
knowledge should be encoded somewhere else in your scripts.


Best,
Raffi


--

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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] Tools for handling cross project dependencies

[Raffi Enficiaud]

Hi CMake,

I am currently working on a toy cmake prototype for Boost. I am not sure 
it will ever be released but I believe it might be useful beyond this 
project.


The idea is to include several "packages" (one package ~ one project in 
Boost) and make those available to the build, exactly as for a regular 
CMakeLists.txt that adds several directories or subprojects through a 
sequence of calls to "add_directories".


However, the difference here is that "packages" have inter-dependencies, 
and the order of the "add_directories" should honor those dependencies.


I developed a rather small CMake script that
* encodes those dependencies in a very simple manner, just by stating 
parent projects in the DAG of dependencies in an appropriate cmake variable,
* runs the ordered inclusion of those dependencies inside the master 
project,


It works like this:
1/ a small "dependencies.cmake" declares the provided components and 
dependencies:
   * a variable that indicates the provided components (say "core", 
"doc" and "test"). Each component defines a CMakeLists.txt
   * a variable that indicates the dependencies to another module (with 
or without components)


2/ a function parses a build tree (not necessarily flat) and detect all 
those dependencies.cmake, loads the containing variables and extract the 
module and components


3/ another function reads the variables set by step 2/ and adds the 
components in the right order


Additional filtering can happen after 2 (already implemented in my 
project) to remove all the packages/components that are not needed for 
the current build, but 3/ will bring any necessary dependency to the build.


A possible example, that can of course be adapted, is given below.

My inquiry there is the following:
* would this be of any interest for the community? I know that some 
projects are struggling with this or provide solutions that, as a 
developer, dislike
* is there already any such mechanism in cmake? I failed to see any, and 
the problem statement is a different than the cmake-package facility 
provided by cmake.


I believe it would also be possible to enhance step 3/ by eg. having a 
logic that checks out the package sources instead of doing an 
"add_directory", and by the possible intermediate filter after step 2/, 
then checking out only what is needed for the end-user/developer.


Thanks!
Raffi



-- Example for Boost.test 

set(_current_package "TEST")
# this declares the components
set(BOOST_LIB_${_current_package}_COMPONENTS "build" "doc" "test")

# this declares the dependencies for the component "build"
set(BOOST_LIB_${_current_package}_COMPONENTS_BUILD_DEPENDENCY
  "system:build"
  "core:build"
  "config:build"
  "predef:build"
)

# same for the component "DOC"
set(BOOST_LIB_${_current_package}_COMPONENTS_DOC_DEPENDENCY )
# same for the component "TEST" (or the module TEST)
set(BOOST_LIB_${_current_package}_COMPONENTS_TEST_DEPENDENCY "test:build")

--

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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] iOS: direction to official support and questions

[Raffi Enficiaud]

Le 27.09.17 à 12:34, Brad King a écrit :

On 09/26/2017 05:05 PM, Raffi Enficiaud wrote:

Is it possible to source the default setup and to override some parts
when a toolchain is given on the command line?


The toolchain file is loaded very early, before any of the platform
information files.  It is supposed to provide information, not consume it.
It is loaded too early to even know CMAKE_SYSTEM_NAME, because it is
supposed to provide this value.


Thanks for the answers!

From what I understand, I missed the point of the cross compilation 
file a bit, and I should rather go for platform files.


For cross-compiling a project on iOS or iOS simulator, and since those 2 
platforms are still Darwin, I believe that:


* from a user perspective:
  * CMAKE_SYSTEM_NAME should be set to "Darwin"
  * CMAKE_SYSTEM_VERSION should be set to iOS or iOS-simulator, 
possibly with a version (like "Mac OSX 10.2" in Darwin.cmake)


* inside "Modules/Platform/Darwin.cmake"
   * CMAKE_SYSTEM_PROCESSOR should default to armXX for iOS and 
i386/x86_64 for the simulator
   * I do not think that any other compiler than AppleClang is 
supported, but we leave the detection as it is right now. This should 
default to AppleClang anyway.
   * the detection of the base SDKs should be performed inside 
"Platform/Darwin.cmake"
   * the file "Modules/Platform/Darwin-Clang.cmake" should check the 
"CMAKE_SYSTEM_VERSION" to add appropriate flags when 
CMAKE_SYSTEM_VERSION is iOS or simulator. This should include clang and 
apple clang.


If things work ok and if I understand more or less the scope of those 
files, the base SDKs will then be detected from the 
"Modules/Platform/Darwin.cmake".


However, I just notice the existence of 
"Modules/Platform/Darwin-Initialize.cmake" that is setting several 
variables. When is this file sourced? should be before 
"Modules/Platform/Darwin.cmake" but I failed to see from where.


I see several problems with this file if I were to make it iOS aware. 
For instance it contains variables that are checking for the version, 
but based only on the macOS scheme.


Should the CMAKE_SYSTEM_VERSION include the "iOS" or "iOSSimulator" 
part? (like for instance "iOS-10.1" ?) or we stick to a clean version 
name and:


1/ either we change the CMAKE_SYSTEM_NAME to DarwinIOS (we also need to 
distinguish between real device and simulator)
2/ or we carry another variable IOS=TRUE and be careful inside the 
Darwin specific platform files.


My preference goes for 2/ above because:
* having something like DarwinIOS would need to create a full new branch 
of platform support, while the overlap with Darwin is almost 95%.
* iOS is clearly a Darwin platform, just another version, but version 
carries more than a revision number (eg "10.5") that needs to be encoded 
in another variable (eg. IOS=TRUE)
* we will benefit from all the build logic (Darwin, policies, etc) that 
are currently working for OSX





Also, is it possible to check for policies directly from the toolchain
file, or is it too early?


In a project that starts with `cmake_minimum_required(...)` as its first
call (the recommended approach) then policies it sets will be available
when the toolchain file is first loaded by a following `project()` or
`enable_language()` command.  However, toolchain files are not meant to
be general-purpose infrastructure shared by many projects.  They are
meant to be specific to a project and host machine.  Common info about
a platform belongs in CMake's modules, e.g. a Platform/iOS.cmake module
for use with CMAKE_SYSTEM_NAME set to "iOS".  Lacking that, a toolchain
file trying to work without it will undoubtedly need to be hacky.


I believe if I integrate well with the platform files, all things would 
be good again, and the policies will apply naturally (so no hack needed).





This is what I added in the toolchain file, but I feel like this is too
hacky:

set(CMAKE_BUILD_WITH_INSTALL_NAME_DIR TRUE)
set(CMAKE_INSTALL_NAME_DIR "@rpath/")
set(CMAKE_BUILD_WITH_INSTALL_RPATH TRUE)
set(CMAKE_INSTALL_RPATH "@rpath/")


If that is universally needed when deploying to iOS then CMake should
be taught this information in a corresponding platform file.


I do not think this is universally needed, I just wanted to mimic the 
default I got when compiling the same source tree but with the OSX 
target platform. Without great success ...




Keeping
it in the toolchain file may work but is an example of the hacky nature
discussed above.  OTOH this looks project-specific to me.  One could
use `@executable_path/` in INSTALL_NAME_DIR for everything and not need
any rpath.


Yes, I was not convinced neither and totally fine with removing this.


and I need to also do this:
set_target_properties(mymainexecutable
   PROPERTIES
 BUILD_WITH_INSTALL_RPATH TRUE
 INSTALL_RPATH &q

Re: [cmake-developers] iOS: direction to official support and questions

[Raffi Enficiaud]

Le 21.09.17 à 23:38, Raffi Enficiaud a écrit :

Le 08.08.17 à 14:08, Raffi Enficiaud a écrit :

Hi CMake ML,

I am quite new to the topic of making toolchain files. However I need to
build a not so trivial application for iOS and I want to do it with
CMake, and if possible walk toward an official support of iOS in CMake.

I have looked a bit to the Android toolchains, and I have to say I found
those quite complicated as a first reading :)

The target application I am building uses Qt and Boost.

So far, I have managed to have an IOS toolchain file that is generating
a looking good XCode project, that I can compile properly (up until
signing).

[snip]


Hi there,

Following the thread, I would like to suggest a toolchain file for iOS,
attached to this post.

I used this to compile a not too small project using Qt, Boost, LSL and
some other fancy dependencies, and the project runs at least on the
simulator (waiting for a real device).

The way it works:

- we need different build trees for the simulator and for a real device
(not same arch nor base SDK). Changing this is way too difficult and the
workaround of having different build trees, although not very "elegant",
just work

- for the simulator
cmake -G Xcode \
  -DCMAKE_TOOLCHAIN_FILE=ios_toolchain.cmake \
  -DIOS_PLATFORM=SIMULATOR \
  ../some-path

- for a real device
cmake -G Xcode \
  -DCMAKE_TOOLCHAIN_FILE=ios_toolchain.cmake \
  -DIOS_PLATFORM=OS \
  ../some-path

- for the device, we need a real certificate for signing that can be set
directly from within XCode or by setting
`XCODE_ATTRIBUTE_CODE_SIGNING_REQUIRED=YES` and the companion variables
to the appropriate values


Next steps:
* I can set up a machine for running the tests as I am doing for the
Matlab package. Those tests would be for the moment compilation tests. I
would be happy to discuss on how to do real "runtime" tests.
* I can proceed further with the documentation of course if people are
happy with this toolchain file
* I can add other SDKs like watchOS and such, but before proceeding
further I would prefer to have a feature complete implementation for iOS
device+simulator (I believe this is the most demanded).
* I can check how to tweak CROSSCOMPILING_EMULATOR to run things on an
emulator in case we are on the simulator. I believe add_test should be
disabled when compiling for a real device
* I would like to know if there is any direction in indicating the
bundles structures, as those are different for iOS and macOS. Right now
I am using a switch like this



Hi CMake,

I do not know if anyone here had the chance to try the previous 
toolchain file.


Since then, I have now a real device and some new fixing has started on 
my side. One of the issues I am facing right now is the one concerning 
the RPATH generation on iOS. I think the best approach is to mimic the 
one for OSX/macOS, but I do not know how this would be feasible.


The main question is:
Is it possible to source the default setup and to override some parts 
when a toolchain is given on the command line?
Also, is it possible to check for policies directly from the toolchain 
file, or is it too early?


This is what I added in the toolchain file, but I feel like this is too 
hacky:


set(CMAKE_BUILD_WITH_INSTALL_NAME_DIR TRUE)
set(CMAKE_INSTALL_NAME_DIR "@rpath/")
set(CMAKE_BUILD_WITH_INSTALL_RPATH TRUE)
set(CMAKE_INSTALL_RPATH "@rpath/")

and I need to also do this:
set_target_properties(mymainexecutable
  PROPERTIES
BUILD_WITH_INSTALL_RPATH TRUE
INSTALL_RPATH "@executable_path/"
)

for the main executable (I need to bundle additional ".dylibs" into the 
main application). For some reason, the CMAKE_* variables do not always 
propagate well to the targets (using cmake 3.7).


Any hint or good practice welcome!

Thanks,
Raffi


--

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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] iOS: direction to official support and questions

[Raffi Enficiaud]

Le 08.08.17 à 14:08, Raffi Enficiaud a écrit :

Hi CMake ML,

I am quite new to the topic of making toolchain files. However I need to
build a not so trivial application for iOS and I want to do it with
CMake, and if possible walk toward an official support of iOS in CMake.

I have looked a bit to the Android toolchains, and I have to say I found
those quite complicated as a first reading :)

The target application I am building uses Qt and Boost.

So far, I have managed to have an IOS toolchain file that is generating
a looking good XCode project, that I can compile properly (up until
signing).

[snip]


Hi there,

Following the thread, I would like to suggest a toolchain file for iOS, 
attached to this post.


I used this to compile a not too small project using Qt, Boost, LSL and 
some other fancy dependencies, and the project runs at least on the 
simulator (waiting for a real device).


The way it works:

- we need different build trees for the simulator and for a real device 
(not same arch nor base SDK). Changing this is way too difficult and the 
workaround of having different build trees, although not very "elegant", 
just work


- for the simulator
cmake -G Xcode \
  -DCMAKE_TOOLCHAIN_FILE=ios_toolchain.cmake \
  -DIOS_PLATFORM=SIMULATOR \
  ../some-path

- for a real device
cmake -G Xcode \
  -DCMAKE_TOOLCHAIN_FILE=ios_toolchain.cmake \
  -DIOS_PLATFORM=OS \
  ../some-path

- for the device, we need a real certificate for signing that can be set 
directly from within XCode or by setting 
`XCODE_ATTRIBUTE_CODE_SIGNING_REQUIRED=YES` and the companion variables 
to the appropriate values



Next steps:
* I can set up a machine for running the tests as I am doing for the 
Matlab package. Those tests would be for the moment compilation tests. I 
would be happy to discuss on how to do real "runtime" tests.
* I can proceed further with the documentation of course if people are 
happy with this toolchain file
* I can add other SDKs like watchOS and such, but before proceeding 
further I would prefer to have a feature complete implementation for iOS 
device+simulator (I believe this is the most demanded).
* I can check how to tweak CROSSCOMPILING_EMULATOR to run things on an 
emulator in case we are on the simulator. I believe add_test should be 
disabled when compiling for a real device
* I would like to know if there is any direction in indicating the 
bundles structures, as those are different for iOS and macOS. Right now 
I am using a switch like this


if(IOS)
  set(OSX_BUNDLE_RELATIVE_PATH ".")
else()
  set(OSX_BUNDLE_RELATIVE_PATH "../..")
endif()

add_custom_command(
TARGET myproj
POST_BUILD
COMMAND ${CMAKE_COMMAND} 
-DAPPFOLDER=$/${OSX_BUNDLE_RELATIVE_PATH} 
   "-DSOMEPARAMS=${BOOST_LIB_PATH}"

-P ${CMAKE_SOURCE_DIR}/cmake/osx_bundle.cmake
)

to get the path to the root folder of the bundle. I do not know if there 
is anything like this in CMake already (the BundleUtilities I believe 
has relative paths written in hard).


Thanks!
Raffi
# cmake -G Xcode \
#  -DCMAKE_TOOLCHAIN_FILE=./ios_toolchain.cmake \
#  -DCMAKE_PREFIX_PATH=~/Qt5.9.1/5.9.1/ios/ \
#  -DBOOST_ROOT=~/Code/SoftwareWorkshop/sw_thirdparties/osx/boost_1_63_0
#  -DBoost_COMPILER=-xgcc42 ../source

# * `IOS`: indicates that the build is being performed for iOS (generic device 
or simulator)
# * `IOS_PLATFORM`: indicates the platform to compile for. This can be the 
genuine operating system (`OS`) or the simulator (`SIMULATOR`)
# * `IOS_ARCH`: the architecture to compile. The default is dependant on the 
`IOS_PLATFORM`:
#* `armv7;arm64` for the `IOS`
#* `i386;x86_64` for the `SIMULATOR`
#
# Other variables
#
# * `CMAKE_IOS_SDK_ROOT`: indicates the name of an SDK to choose, defaults to 
the "most recent" SDK
#
# By default code signing is `OFF`, but should be activated per target in order 
to have the compilation
# possible for iOS device (Xcode defaults to some ad-hox signing otherwise). 
This can be done
# through the target properties `XCODE_ATTRIBUTE_CODE_SIGNING_REQUIRED`

# TODO
# - documentation
# - detects automatically sdks and target systems from XCode, and lists the 
sysroots
# - this is for IOS only, not watchOS or anything else
# - indicate the bundle structure for this target system (different than from 
macOS)
# - indicate how to run tests maybe through `CROSSCOMPILING_EMULATOR`
# - fix the tests
# - find other libraries that clang/clang++ ?


# some relevant doc/resources
# 
https://developer.apple.com/library/content/documentation/DeveloperTools/Conceptual/cross_development/Using/using.html#//apple_ref/doc/uid/20002000-SW6

# for running simulator
# 
https://stackoverflow.com/questions/26031601/xcode-6-launch-simulator-from-command-line
# can be consumed with
# https://cmake.org/cmake/help/v3.8/prop_tgt/CROSSCOMPILING_EMULATOR.html

# Raffi: automated code signing
# public.kitware.com/pipermail/cmake/2016.../064602.html
# set_target_properties

Re: [cmake-developers] iOS: direction to official support and questions

[Raffi Enficiaud]

Le 16.08.17 à 16:27, Eric Wing a écrit :

I've been using a derivative of the iOS toolchain for many years that
you probably can find easily with a Google search. It has a lot of
shortcomings, but it generally works. And most of the shortcomings I
think are only solvable by properly fixing/modifying the CMake core.


Hi,

thanks for your answer. I also found several examples online, some of 
them are good, but I cannot just copy-paste them :) I need to understand 
what is going on, and sometimes things are done not in a good way.





On 8/15/17, Raffi Enficiaud <raffi.enfici...@mines-paris.org> wrote:

Le 10.08.17 à 17:04, Brad King a écrit :

On 08/08/2017 08:08 AM, Raffi Enficiaud wrote:

I have looked a bit to the Android toolchains, and I have to say I found
those quite complicated as a first reading :)




I personally think the Android toolchain is way more complicated than
the iOS toolchain. Among the reasons are that every NDK release broke
something different as they kept changing the compiler and conventions
(the gcc to clang move was the most recent biggie, but old-timers
might remember the standalone toolchain difficulties.). Then you have
to pick different API levels because the each NDK release ships a
separate API subtarget for all prior versions of Android. Then add all
the multiple architectures (mips, arm, x86, 64-bit) and the
subvariants (armv5, armv7, armv7+NEON, etc), 4 different C++ standard
libraries you have to choose from, and other nuisances like Android on
Windows...makes the whole thing a mess.


Right now, I am completely discarding whatever has been done for Android :)





Ideally CMake would gain iOS platform modules such that one could
set CMAKE_SYSTEM_NAME to `iOS`.




where this path is hard coded, and points to the fat static libraries
prefix path of boost. If I remove this path, FindBoost does not find the
boost libraries anymore (of course I am passing BOOST_ROOT). In
addition, I have this:

set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)


These last three lines tell the find commands to only look at
paths re-rooted under CMAKE_FIND_ROOT_PATH and CMAKE_SYSROOT.
If boost is not under one of those then it won't be found.



That sounds right. The general problem is you don't want to
accidentally pick up OSX stuff on your system.


It appears that this is too restrictive. For instance, I compiled boost 
and made fat libraries in an installation folder, and I am not being 
able to pick them up. By removing them, FindBoost works fine.


But the problem is that it is unclear to me what should be allowed and 
what not, and where are the problems:
* specifically for the FindBoost problem mentioned above, is it a 
limitation of FindBoost that is not honouring cross compilation well? I 
believe that if I provide a BOOST_ROOT, then it should be used no matter 
what default configuration is provided by the toolchain file
* another example: I need eg. the python interpreter to run some tests. 
If I remove the lines above, the host interpreter is found. In the case 
of my project, it is ok, because I use that for running some tests. In 
some other projects I have, I think this is not ok because I may use the 
interpreter for finding other libraries on the OS (cython, numpy, etc).


The question is:
what is the best practice for letting the developer do his job right?

Preventing accessing some paths when searching for a binary or a 
shared/library is limiting. Especially, it is not easy to know if a 
library that is found is part of the cross-compilation toolchain that 
can run on the host (say "codesign", "clang", "python" etc) or part of 
the bundle we want to create (eg boost_something.dylib, that is a fat 
binary containing also the architecture of the host - because of the iOS 
simulator).


As of today, find_library or find_program does not make any distinction, 
but in case of cross-compilation, I would like to have ideally a 
"CROSS_COMPILATION_TOOLCHAIN" property that I may use in the CMake scripts.


For instance, I need to find a library that will be integrated in the 
target platform binary:




find_library(MyLIB
NAMES my_lib_arch_arm
TARGET_PLATFORM) # or TARGET_PLATFORM implicit

add_executable(MyFinalBundle ... TARGET_PLATFORM)
target_link_library(MyFinalBundle MyLIB) # check for consistency: all 
dependencies should be TARGET_PLATFORM as well



In this case, the find_library will look into the sysroot that is 
provided by the toolchain file, plus some given by the user and that are 
specific to the module (BOOST_ROOT for instance)


OTOH:

find_library(MyToolchainLib
NAMES my_toolchainlib
HOST_PLATFORM)

find_program(my_other_toolchain_program
HOST_PLATFORM)

add_executable(my_intermediade_tool HOST_PLATFORM)
target_link_library(my_intermediade_tool MyToolchainLib)

add_cus

Re: [cmake-developers] iOS: direction to official support and questions

[Raffi Enficiaud]

Le 10.08.17 à 17:04, Brad King a écrit :

On 08/08/2017 08:08 AM, Raffi Enficiaud wrote:

I have looked a bit to the Android toolchains, and I have to say I found
those quite complicated as a first reading :)


This note may help:

 https://gitlab.kitware.com/cmake/cmake/issues/16708#note_300971


Hi,
Thanks for the link and the answers!



I don't think iOS will need all the toolchain and stl selection logic.

Ideally CMake would gain iOS platform modules such that one could
set CMAKE_SYSTEM_NAME to `iOS`.


set(CMAKE_FIND_ROOT_PATH
 ${CMAKE_IOS_DEVELOPER_ROOT}
 ${CMAKE_IOS_SDK_ROOT}
 ${CMAKE_PREFIX_PATH}
 /path/to/boost_1_64_0_build/install
 CACHE string  "iOS find search path root")
```

where this path is hard coded, and points to the fat static libraries
prefix path of boost. If I remove this path, FindBoost does not find the
boost libraries anymore (of course I am passing BOOST_ROOT). In
addition, I have this:

set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)


These last three lines tell the find commands to only look at
paths re-rooted under CMAKE_FIND_ROOT_PATH and CMAKE_SYSROOT.
If boost is not under one of those then it won't be found.


set(CMAKE_MACOSX_BUNDLE YES)


Is it possible to build any binary of any form on iOS without this?


You're right, I do not think this is possible.


If not then the iOS platform modules should set something to tell
the generators that this should always be enabled.


set(CMAKE_XCODE_ATTRIBUTE_CODE_SIGNING_REQUIRED "NO")


Similarly for this, but perhaps only during `try_compile`.


What I understand from this variable is that, it sets the default of 
CODE_SIGNING_REQUIRED to "NO", and this can be overriden per target by 
setting the XCODE_ATTRIBUTE_CODE_SIGNING_REQUIRED target property to 
something else.


Is that correct?

I believe that for iOS developments, the default should rather be the 
opposite, and the try_compile should be informed of not trying to sign 
the app, via "some mechanism" as you suggested.


Concerning this "some mechanism" part, what do you have in mind? Would 
it be an extra variable like 
CMAKE_XCODE_ATTRIBUTE_CODE_SIGNING_REQUIRED_IN_TRY_COMPILE ?


What I fail to understand here, is the purpose of the "try_compile" that 
is performed at the beginning. Isn't this try_compile supposed to 
compile source files only, without trying to link nor bundle anything? 
If this is the case, signing the result is irrelevant, and I do not 
understand why this fails.


If you have an idea, good, otherwise I believe this is secondary right now.


I'm not familiar enough with iOS development to answer the rest of
your questions.


Me neither :)

Currently the main issue I am seeing is the multiarch/multisysroot 
target of XCode that is kind of lost when using CMake. By 
multiarch/multisysroot, I mean that Xcode is able to switch from 
iPhoneSimulatorXY to iPhoneXY without changing the project, and within 
the same view.


The switching means changing the target architecture, as well as 
changing the SYSROOT. I checked the command lines emitted by XCode, and 
it changes the "-isysroot" flag based on the type of target.


From the posts I can read online, this is causing a lot of troubles, 
especially when linking with libraries.


For users' libraries, the workaround is to have fat libraries by 
combining all the target archs into one with lipo. The compilation is 
done with different "-isysroot" then. What I understood is that Apple is 
discouraging this, and this is for me not a proper solution neither, but 
might work.


The real problem seems to be when linking to system libraries, those 
that are under sysroot, and I cannot find a good answer to this.


Example:

Suppose in the toolchain file, we have something like this, where 
CMAKE_IOS_SDK_ROOT depends on the fact that we use the simulator or not:


'''
set(CMAKE_FIND_ROOT_PATH
${CMAKE_IOS_DEVELOPER_ROOT}
${CMAKE_IOS_SDK_ROOT}
${CMAKE_PREFIX_PATH}
/some/other/path
CACHE string  "iOS find search path root")

# set up the default search directories for frameworks
set (CMAKE_SYSTEM_FRAMEWORK_PATH
${CMAKE_IOS_SDK_ROOT}/System/Library/Frameworks
${CMAKE_IOS_SDK_ROOT}/System/Library/PrivateFrameworks
${CMAKE_IOS_SDK_ROOT}/Developer/Library/Frameworks
)
'''

and later in our CMakeLists, we have eg.

'''
find_package(ZLIB REQUIRED)
'''

The selection of the SYSROOT is done then on the cmd line given to 
CMake, and set up once.


The library that is found by ZLIB are related to CMAKE_IOS_SDK_ROOT, 
that is a constant in a build tree. Although Xcode can reroot the 
SYSROOT depending on the target device/arch (simulator/non-simulator).


Even if later XCode is able to switch sysroots on the command line, 
depending on the target, the libraries we are linking 

Re: [cmake-developers] Passing lists with generator expression through add_custom_command

[Raffi Enficiaud]

Le 15.08.17 à 16:48, Brad King a écrit :

On 08/13/2017 11:36 AM, Raffi Enficiaud wrote:

-DALL_DEPENDENCIES="${ALL_DEPENDENCIES_FILES}"


That is actually an unquoted argument whose value contains literal quotes.
See the cmake-language(7) manual for details on the syntax.  Switch it to

  "-DALL_DEPENDENCIES=${ALL_DEPENDENCIES_FILES}"

to quote the argument so that add_custom_command receives it unexpanded.
Then use the VERBATIM option to add_custom_command to make sure it is
re-escaped for the shell properly.

-Brad



Ahh, thanks! and sorry for the noise!

Raffi

--

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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] iOS: direction to official support and questions

[Raffi Enficiaud]

Hi CMake ML,

I am quite new to the topic of making toolchain files. However I need to 
build a not so trivial application for iOS and I want to do it with 
CMake, and if possible walk toward an official support of iOS in CMake.


I have looked a bit to the Android toolchains, and I have to say I found 
those quite complicated as a first reading :)


The target application I am building uses Qt and Boost.

So far, I have managed to have an IOS toolchain file that is generating 
a looking good XCode project, that I can compile properly (up until 
signing).


I can share the toolchain file: it is a collection of things I have 
found on the internet, but trimmed from what I think was not necessary. 
It is still in a not so nice state, but I am currently cleaning it.


There are things that I think are weird though:

* I need to have:
```
set(CMAKE_FIND_ROOT_PATH
${CMAKE_IOS_DEVELOPER_ROOT}
${CMAKE_IOS_SDK_ROOT}
${CMAKE_PREFIX_PATH}
/path/to/boost_1_64_0_build/install
CACHE string  "iOS find search path root")
```

where this path is hard coded, and points to the fat static libraries 
prefix path of boost. If I remove this path, FindBoost does not find the 
boost libraries anymore (of course I am passing BOOST_ROOT). In 
addition, I have this:


```
set (CMAKE_SYSTEM_FRAMEWORK_PATH
${CMAKE_IOS_SDK_ROOT}/System/Library/Frameworks
${CMAKE_IOS_SDK_ROOT}/System/Library/PrivateFrameworks
${CMAKE_IOS_SDK_ROOT}/Developer/Library/Frameworks
)

set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
```

this looks ok to me, as we are cross compiling.
Is this a problem of FindBoost, or the combinations of the options that 
are not ok?


* I need to add:
```
set(CMAKE_MACOSX_BUNDLE YES)
set(CMAKE_XCODE_ATTRIBUTE_CODE_SIGNING_REQUIRED "NO")
```

and this comes from https://public.kitware.com/Bug/view.php?id=15329 . 
As I understand it, this is a problem of try_compile: as signing of 
application is required for generating a binary for iOS, this one fails 
very early when CMake discovers the capabilities of the compiler. Some 
people made a workaround by short-cutting the compiler checks, which is 
to me a wrong direction to take. As mentioned in this ticket, the right 
solution would be that the try_compile commands not to require signing 
of the binaries (or sthg similar).

This is explained here: http://public.kitware.com/Bug/view.php?id=12288

* is this one https://cmake.org/Bug/view.php?id=12640 addressed?

* I am seeing exchanges concerning the IOS_INSTALL_COMBINED. Does this 
has something to do with toolchain? What is meant by "installation" in 
this case? Sorry for my naive question, but I do not understand the 
workflow very well.


* how can I have unit tests of the toolchain in a CI fashion. Ideally, I 
would like to have a target cross-compiled with this toolchain, and then 
running the iPhoneSimulator, and check the result (return code, process, 
command whatever).

Does anyone have experience with this?

Thanks,
Raffi




--

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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.7.0-rc1 now ready for testing!

[Raffi Enficiaud]

Le 04/10/16 à 22:32, Robert Maynard a écrit :

I am proud to announce the first CMake 3.7 release candidate.
  https://cmake.org/download/

Documentation is available at:
  https://cmake.org/cmake/help/v3.7

Release notes appear below and are also published at
  https://cmake.org/cmake/help/v3.7/release/3.7.html

[snip]


Modules
---
[snip]



* The "FindMatlab" module learned to find a SIMULINK component.


Hi there,

Please add the following to the changelog of the FindMatlab module:

The FindMatlab module learned to find the SIMULINK and MAT components. 
The matlab_add_mex command can now add executable and module mex files, 
and matlab_add_unit_test can now run inline matlab test code.


Thanks!
Raffi


--

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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-commits] CMake branch, next, updated. v3.6.2-1841-gac75ecc

[Raffi Enficiaud]

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

The branch, next has been updated
   via  ac75ecc1800c224c803b1de2af49f071b6aee36c (commit)
   via  5d0d9b36f26221e2de96bce2afb6334f2b8e8454 (commit)
  from  6dfacdc467dc87ef45a61359039003ba2f4a5d79 (commit)

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

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ac75ecc1800c224c803b1de2af49f071b6aee36c
commit ac75ecc1800c224c803b1de2af49f071b6aee36c
Merge: 6dfacdc 5d0d9b3
Author: Raffi Enficiaud <raffi.enfici...@mines-paris.org>
AuthorDate: Thu Sep 8 07:25:16 2016 -0400
Commit: CMake Topic Stage <kwro...@kitware.com>
CommitDate: Thu Sep 8 07:25:16 2016 -0400

Merge topic 'FindMatlab-regression-tests-print-on-error' into next

5d0d9b36 CMake Nightly Date Stamp


---

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


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

[Cmake-commits] CMake branch, next, updated. v3.6.1-1612-g94b028b

[Raffi Enficiaud]

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

The branch, next has been updated
   via  94b028b48a1d7f1fe753bd4e626f24d4240c7436 (commit)
   via  bf09271b656bb8110c40cd2d456acfaa3b4e4741 (commit)
  from  ef65af0eeccf9a0137c258e5d5efa7e729cb2072 (commit)

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

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=94b028b48a1d7f1fe753bd4e626f24d4240c7436
commit 94b028b48a1d7f1fe753bd4e626f24d4240c7436
Merge: ef65af0 bf09271
Author: Raffi Enficiaud <raffi.enfici...@mines-paris.org>
AuthorDate: Tue Aug 30 10:04:06 2016 -0400
Commit: CMake Topic Stage <kwro...@kitware.com>
CommitDate: Tue Aug 30 10:04:06 2016 -0400

Merge topic 'FindMatlab-additional-components' into next

bf09271b FindMatlab: adding handling of component "MAT"


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=bf09271b656bb8110c40cd2d456acfaa3b4e4741
commit bf09271b656bb8110c40cd2d456acfaa3b4e4741
Author: Raffi Enficiaud <raffi.enfici...@mines-paris.org>
AuthorDate: Tue Aug 30 14:50:20 2016 +0200
Commit: Raffi Enficiaud <raffi.enfici...@mines-paris.org>
CommitDate: Tue Aug 30 14:50:20 2016 +0200

FindMatlab: adding handling of component "MAT"

- documentation
- test
- cosmetic changes

diff --git a/Modules/FindMatlab.cmake b/Modules/FindMatlab.cmake
index 46285aa..9f96fe6 100644
--- a/Modules/FindMatlab.cmake
+++ b/Modules/FindMatlab.cmake
@@ -15,8 +15,8 @@
 #
 # The module supports the following components:
 #
-# * ``MX_LIBRARY`` and ``ENG_LIBRARY`` respectively the MX and ENG libraries of
-#   Matlab
+# * ``MX_LIBRARY``, ``ENG_LIBRARY`` and ``MAT_LIBRARY``: respectively the MX,
+#   ENG and MAT libraries of Matlab
 # * ``MAIN_PROGRAM`` the Matlab binary program.
 #
 # .. note::
@@ -93,6 +93,9 @@
 # ``Matlab_ENG_LIBRARY``
 #   Matlab engine library. Available only if the component ``ENG_LIBRARY``
 #   is requested.
+# ``Matlab_MAT_LIBRARY``
+#   Matlab matrix library. Available only if the component ``MAT_LIBRARY``
+#   is requested.
 # ``Matlab_LIBRARIES``
 #   the whole set of libraries of Matlab
 # ``Matlab_MEX_COMPILER``
@@ -1213,6 +1216,7 @@ if(DEFINED Matlab_ROOT_DIR_LAST_CACHED)
 Matlab_MAIN_PROGRAM
 Matlab_MX_LIBRARY
 Matlab_ENG_LIBRARY
+Matlab_MAT_LIBRARY
 Matlab_MEX_EXTENSION
 
 # internal
@@ -1346,7 +1350,6 @@ _Matlab_find_library(
   NO_DEFAULT_PATH
 )
 
-
 list(APPEND _matlab_required_variables Matlab_MEX_LIBRARY)
 
 # the MEX extension is required
@@ -1355,7 +1358,6 @@ list(APPEND _matlab_required_variables 
Matlab_MEX_EXTENSION)
 # the matlab root is required
 list(APPEND _matlab_required_variables Matlab_ROOT_DIR)
 
-
 # component Mex Compiler
 list(FIND Matlab_FIND_COMPONENTS MEX_COMPILER _matlab_find_mex_compiler)
 if(_matlab_find_mex_compiler GREATER -1)
@@ -1366,7 +1368,6 @@ if(_matlab_find_mex_compiler GREATER -1)
 DOC "Matlab MEX compiler"
 NO_DEFAULT_PATH
   )
-
   if(Matlab_MEX_COMPILER)
 set(Matlab_MEX_COMPILER_FOUND TRUE)
   endif()
@@ -1376,7 +1377,6 @@ unset(_matlab_find_mex_compiler)
 # component Matlab program
 list(FIND Matlab_FIND_COMPONENTS MAIN_PROGRAM _matlab_find_matlab_program)
 if(_matlab_find_matlab_program GREATER -1)
-
   find_program(
 Matlab_MAIN_PROGRAM
 matlab
@@ -1384,11 +1384,9 @@ if(_matlab_find_matlab_program GREATER -1)
 DOC "Matlab main program"
 NO_DEFAULT_PATH
   )
-
   if(Matlab_MAIN_PROGRAM)
 set(Matlab_MAIN_PROGRAM_FOUND TRUE)
   endif()
-
 endif()
 unset(_matlab_find_matlab_program)
 
@@ -1402,14 +1400,12 @@ if(_matlab_find_mx GREATER -1)
 PATHS ${_matlab_lib_dir_for_search}
 NO_DEFAULT_PATH
   )
-
   if(Matlab_MX_LIBRARY)
 set(Matlab_MX_LIBRARY_FOUND TRUE)
   endif()
 endif()
 unset(_matlab_find_mx)
 
-
 # Component ENG library
 list(FIND Matlab_FIND_COMPONENTS ENG_LIBRARY _matlab_find_eng)
 if(_matlab_find_eng GREATER -1)
@@ -1426,15 +1422,26 @@ if(_matlab_find_eng GREATER -1)
 endif()
 unset(_matlab_find_eng)
 
-
-
+# Component MAT library
+list(FIND Matlab_FIND_COMPONENTS MAT_LIBRARY _matlab_find_mat)
+if(_matlab_find_mat GREATER -1)
+  _Matlab_find_library(
+${_matlab_lib_prefix_for_search}
+Matlab_MAT_LIBRARY
+mat
+PATHS ${_matlab_lib_dir_for_search}
+NO_DEFAULT_PATH
+  )
+  if(Matlab_MAT_LIBRARY)
+set(Matlab_MAT_LIBRARY_FOUND TRUE)
+  endif()
+endif()
+unset(_matlab_find_mat)
 
 
 unset(_matlab_lib_dir_for_search)
 
-
-set(Matlab_LIBRARIES ${Matlab_MEX_LIBRARY} ${Matlab_MX_LIBRARY} 
${Matlab_ENG_LIBRARY})
-
+set(Matlab_LIBRARIES ${Matlab_MEX_LIBRARY} ${Matlab_MX_LIBRARY} 
${Matlab_ENG_LIBRA

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

[Raffi Enficiaud]

Le 13/11/15 09:30, Domen Vrankar a écrit :

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.



Indeed, but please note that for being able to support multipackaging 
(ie. creating multiple valid components on eg. Launchpad), the patch 
with the Source field is still needed (which was included post 3.4 freeze).


At least, this is enough for having your packages built on your own ppa 
on Launchpad (3.4.1 should include the Source field as well). Note: the 
new version of cmake should also be referenced by your PPA.


Raffi

--

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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

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


Thanks,
Raffi
>From 4c7f916f7eb6088f4b07864584dae69c0976e5cf Mon Sep 17 00:00:00 2001
From: Raffi Enficiaud <raffi.enfici...@mines-paris.org>
Date: Tue, 3 Nov 2015 01:44:30 +0100
Subject: [PATCH] CPackDeb: adding tests to the compression scheme leak

---
 Tests/CMakeLists.txt   |  3 +-
 .../MyLibCPackConfig-compression.cmake.in  | 11 +
 .../RunCPackVerifyResult-compression.cmake | 55 ++
 .../CPackComponentsDEB/RunCPackVerifyResult.cmake  |  7 ++-
 4 files changed, 73 insertions(+), 3 deletions(-)
 create mode 100644 
Tests/CPackComponentsDEB/MyLibCPackConfig-compression.cmake.in
 create mode 100644 
Tests/CPackComponentsDEB/RunCPackVerifyResult-compression.cmake

diff --git a/Tests/CMakeLists.txt b/Tests/CMakeLists.txt
index 2c6a42c..d223f99 100644
--- a/Tests/CMakeLists.txt
+++ b/Tests/CMakeLists.txt
@@ -1034,7 +1034,8 @@ ${CMake_BINARY_DIR}/bin/cmake -DDIR=dev -P 
${CMake_SOURCE_DIR}/Utilities/Release
  "components-description2"
  "components-shlibdeps1"
  "components-depend1"
- "components-depend2")
+ "components-depend2"
+ "compression")
   set(CPackGen "DEB")
   set(CPackRun_CPackGen "-DCPackGen=${CPackGen}")
 
diff --git a/Tests/CPackComponentsDEB/MyLibCPackConfig-compression.cmake.in 
b/Tests/CPackComponentsDEB/MyLibCPackConfig-compression.cmake.in
new file mode 100644
index 000..ff18834
--- /dev/null
+++ b/Tests/CPackComponentsDEB/MyLibCPackConfig-compression.cmake.in
@@ -0,0 +1,11 @@
+#
+# Test that setting the compression produces valid
+# packages (compression does not leak to the DEBIAN/ files that use gzip)
+#
+
+if(CPACK_GENERATOR MATCHES "DEB")
+   set(CPACK_DEB_COMPONENT_INSTALL "OFF")
+endif()
+
+set(CPACK_COMPONENTS_ALL_GROUPS_IN_ONE_PACKAGE)
+set(CPACK_DEBIAN_COMPRESSION_TYPE xz)
diff --git a/Tests/CPackComponentsDEB/RunCPackVerifyResult-compression.cmake 
b/Tests/CPackComponentsDEB/RunCPackVerifyResult-compression.cmake
new file mode 100644
index 000..dbd4b2b
--- /dev/null
+++ b/Tests/CPackComponentsDEB/RunCPackVerifyResult-compression.cmake
@@ -0,0 +1,55 @@
+if(NOT CPackComponentsDEB_SOURCE_DIR)
+  message(FATAL_ERROR "CPackComponentsDEB_SOURCE_DIR not set")
+endif()
+
+include(${CPackComponentsDEB_SOURCE_DIR}/RunCPackVerifyResult.cmake)
+
+# TODO: currently debian doens't produce lower cased names
+set(expected_file_mask "${CPackComponentsDEB_BINARY_DIR}/MyLib-*.deb")
+set(expected_count 1)
+
+
+set(actual_output)
+run_cpack(actual_output
+  CPack_output
+  CPack_error
+  EXPECTED_FILE_MASK "${expected_file_mask}"
+  CONFIG_ARGS "${config_args}"
+  CONFIG_VERBOSE "${config_verbose}")
+
+if(NOT actual_output)
+  message(STATUS "expected_count='${expected_count}'")
+  message(STATUS "expected_file_mask='${expected_file_mask}'")
+  message(STATUS "actual_output_files='${actual_output}'")
+  message(FATAL_ERROR "error: expected_files do not exist: CPackComponentsDEB 
test fails. (CPack_output=${CPack_output}, CPack_error=${CPack_error}")
+endif()
+
+list(LENGTH actual_output actual_count)
+if(NOT actual_count EQUAL expected_count)
+  message(STATUS "actual_count='${actual_count}'")
+  message(FATAL_ERROR "error: expected_count=${expected_count} does not match 
actual_count=${actual_count}: CPackComponents test fails. 
(CPack_output=${CPack_output}, CPack_error=${CPack_error})")
+endif()
+
+
+# dpkg-deb checks
+find_program(DPKGDEB_EXECUTABLE dpkg-deb)
+if(DPKGDEB_EXECUTABLE)
+  set(dpkgdeb_output_errors_all "")
+  foreach(_f IN LISTS actual_output)
+run_dpkgdeb(dpkg_output
+FILENAME "${_f}"
+)
+
+# message(FATAL_ERROR "output = '${dpkg_output}'")
+if("${dpkg_output}" STREQUAL "")
+  set(dpkgdeb_output_errors_all "${dpkgdeb_output_errors_all}"
+"dpkg-deb: ${_f}: empty content returned 
by dpkg-deb")
+endif()
+  endforeach()
+
+  if(NOT "${

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

[Raffi Enficiaud]

Hi all,

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


For the little story, this field references the source package (with 
possible revision number) that was used to generate the binary package. 
This is indeed needed when several .deb packages are generated by one 
source tree, otherwise the generated binary packages are rejected by eg. 
Launchpad at the upload step.
Without this patch, mono-component installs work as expected (see cmake 
below).


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


https://code.launchpad.net/~raffi-enficiaud-x/+archive/ubuntu/yayi/+packages

Also, I would like to announce that I created a little "debian/" folder 
for the cmake project that allows to build "cmake" on Launchpad without 
any effort/hassle, just by using a few dpkg tools and the cmake CPackDEB 
machinery (based on the previous improvements of CPackDEB):


https://bitbucket.org/renficiaud/cmake-debian-ppa/src/3f79ec63ccdc331a7142f2088cd5e0311d04c7cc?at=master

The generated cmake debian packages are also in the same PPA.

I would be happy to know more about the best practices for being able to 
generate multiple Debian packages from one source. Any comments more 
than welcome.


Kind regards,
Raffi Enficiaud


PS: I posted on the gmane.linux.debian.devel.mentors list in the 
following thread 
http://thread.gmane.org/gmane.linux.debian.devel.mentors/72992
From c8fdbafdff7ed2556be53371a2357aa82ad6db5c Mon Sep 17 00:00:00 2001
From: Raffi Enficiaud <raffi.enfici...@mines-paris.org>
Date: Wed, 28 Oct 2015 23:59:42 +0100
Subject: [PATCH] CPackDEB: handling binary packages "Source" field

- CPackeDEB now honour the Source field with multicomponent support
- minor documentation enhancements
---
 Modules/CPackDeb.cmake | 48 --
 Source/CPack/cmCPackDebGenerator.cxx   |  7 ++
 Tests/CMakeLists.txt   |  3 +-
 .../MyLibCPackConfig-components-source.cmake.in| 33 ++
 .../RunCPackVerifyResult-components-source.cmake   | 75 ++
 5 files changed, 158 insertions(+), 8 deletions(-)
 create mode 100644 
Tests/CPackComponentsDEB/MyLibCPackConfig-components-source.cmake.in
 create mode 100644 
Tests/CPackComponentsDEB/RunCPackVerifyResult-components-source.cmake

diff --git a/Modules/CPackDeb.cmake b/Modules/CPackDeb.cmake
index 60e0d1f..3b82c73 100644
--- a/Modules/CPackDeb.cmake
+++ b/Modules/CPackDeb.cmake
@@ -8,7 +8,7 @@
 # ^^
 #
 # CPackDeb may be used to create Deb package using CPack.
-# CPackDeb is a CPack generator thus it uses the CPACK_XXX variables
+# CPackDeb is a CPack generator thus it uses the `CPACK_XXX` variables
 # used by CPack : https://cmake.org/Wiki/CMake:CPackConfiguration.
 # CPackDeb generator should work on any linux host but it will produce
 # better deb package when Debian specific tools 'dpkg-xxx' are usable on
@@ -18,7 +18,7 @@
 # :code:`CPACK_DEBIAN_XXX` variables.
 #
 # :code:`CPACK_DEBIAN__` variables may be used in order to have
-# **component** specific values.  Note however that  refers to the
+# **component** specific values.  Note however that `` refers to the
 # **grouping name** written in upper case. It may be either a component name or
 # a component GROUP name.
 #
@@ -354,7 +354,28 @@
 #set by Debian policy
 #
https://www.debian.org/doc/debian-policy/ch-files.html#s-permissions-owners
 #
-
+# .. variable:: CPACK_DEBIAN_PACKAGE_SOURCE
+#   CPACK_DEBIAN__PACKAGE_SOURCE
+#
+#  Sets the `Source` field of the binary Debian package.
+#  When the binary package name is not the same as the source package name
+#  in particular when several components/binaries are generated from one 
source)
+#  the source from which the binary has been generated should be indicated with
+#  the field `Source`.
+#
+#  * Mandatory : NO
+#  * Default   :
+#
+#- An empty string for non-component based installations
+#- :variable:`CPACK_DEBIAN_PACKAGE_SOURCE` for component-based
+#  installations.
+#
+#  See 
https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Source
+#
+#  .. note::
+#
+#This value is not interpreted, it is then possible to pass an optional
+#revision number for the referenced source package as well.
 
 #=
 # Copyright 2007-2009 Kitware, Inc.
@@ -554,6 +575,16 @@ function(cpack_deb_prepare_package_vars)
   )
   endif()
 
+  # Source: (optional)
+  # in case several packages are constructed from a unique source
+  # (multipackaging), the the source may be indicated as well.
+  # The source might contain a version if the generated package
+  

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

[Raffi Enficiaud]

Le 23/10/15 11:22, Nils Gladitz a écrit :

Given this test case:
   cmake_minimum_required(VERSION 3.3)

   project(Foo NONE)

   install(FILES CMakeLists.txt DESTINATION tmp)

   set(CPACK_DEBIAN_COMPRESSION_TYPE "xz")
   set(CPACK_PACKAGE_CONTACT "f...@bar.com")

   include(CPack)

A debian package created with:
 cpack -G DEB

Fails during installation with dpkg -i with:
   tar: Archive is compressed. Use -J option
   tar: Error is not recoverable: exiting now
   dpkg-deb: error: subprocess tar returned error exit status 2

The breaking commit seems to be:
 7044e8ee4baa8250fd9c4e915b13d53c7f543ea3 CPackDeb: use of
libarchive and removal of fakeroot

 From the looks of it the contained "control.tar.gz" is now XZ
compressed as well while it previously was gzip compressed.

Nils


Fix attached! (based on current master a03c13a)
Thank you for the report.

Best,
Raffi

PS.: I will add the test later today
>From fd9693db2b4dcdf6cc9ce5320c009b7e20533756 Mon Sep 17 00:00:00 2001
From: Raffi Enficiaud <raffi.enfici...@mines-paris.org>
Date: Fri, 23 Oct 2015 12:01:35 +0200
Subject: [PATCH] fixup! CPackDEB proper compression scheme for control.tar.gz

---
 Source/CPack/cmCPackDebGenerator.cxx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Source/CPack/cmCPackDebGenerator.cxx 
b/Source/CPack/cmCPackDebGenerator.cxx
index 93c94e2..04efb71 100644
--- a/Source/CPack/cmCPackDebGenerator.cxx
+++ b/Source/CPack/cmCPackDebGenerator.cxx
@@ -570,7 +570,7 @@ int cmCPackDebGenerator::createDeb()
   return 0;
   }
 cmArchiveWrite control_tar(fileStream_control_tar,
-   tar_compression_type,
+   cmArchiveWrite::CompressGZip,
"paxr");
 
 // sets permissions and uid/gid for the files
-- 
2.0.1

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] CPack Debian

[Raffi Enficiaud]

Le 10/10/15 14:36, Robert Bielik a écrit :

Hi Raffi,

It works nicely with the new debian backend, thanks!

Regards
/R


Great! I am on my side still experiencing some issues with Launchpad...

Best,
Raffi


--

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] CPack Debian

[Raffi Enficiaud]

Le 09/10/15 15:37, Robert Bielik a écrit :

Den 2015-10-09 kl. 15:36, skrev Robert Bielik:

I saw that Rafael introduced libarchive in commit 7044e8ee4, which
seems to be set to both produce tars without sparse files, and having
root:root as user.

Sorry, that would be Raffi ;)



Yep :)

Targeted for cmake 3.4. Maybe you can give a try to the RC?

Best,
Raffi


--

Powered by www.kitware.com

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

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

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

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

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

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

[Raffi Enficiaud]

Le 22/09/15 12:03, Domen Vrankar a écrit :

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



Thanks,

I was not sure about the CPack part.
Hopefully now I will be able to build my package on Launchpad :)

Best,
Raffi

--

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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

[Raffi Enficiaud]

Le 17/09/15 21:21, Domen Vrankar a écrit :

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.


Super, thanks!

Raffi


--

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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

[Raffi Enficiaud]

Le 15/09/15 08:43, Domen Vrankar a écrit :

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?


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

--

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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

[Raffi Enficiaud]

Le 15/09/15 11:00, Domen Vrankar a écrit :


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?



I think those are not really just "guidelines" if you want ever your 
source package be published with a cmake toolchain (severity "serious").


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 .


I added a test over lintian again, as I think lintian is the official 
tool for checking those things.


Please note that I was not able to check the produced documentation 
(although I updated it). I would be happy if you can do it, otherwise I 
will do tonight.


Thanks!
Raffi

PS.: what about the other patches?
>From 36f273c1e07651060deaea3b576150151ed65818 Mon Sep 17 00:00:00 2001
From: Raffi Enficiaud <raffi.enfici...@mines-paris.org>
Date: Tue, 15 Sep 2015 11:26:53 +0200
Subject: [PATCH] fixUp! permissions on control files and strict Debian rules
 variable

---
 Modules/CPackDeb.cmake  | 30 ++---
 Source/CPack/cmCPackDebGenerator.cxx| 39 ++---
 Tests/CPackComponentsDEB/CMakeLists.txt | 19 
 3 files changed, 82 insertions(+), 6 deletions(-)

diff --git a/Modules/CPackDeb.cmake b/Modules/CPackDeb.cmake
index 754df91..43b49f8 100644
--- a/Modules/CPackDeb.cmake
+++ b/Modules/CPackDeb.cmake
@@ -330,9 +330,30 @@
 #  .. note::
 #
 #The original permissions of the files will be used in the final
-#package. In particular, the scripts should have the proper executable
+#package unless the variable
+#:variable:`CPACK_DEBIAN_PACKAGE_CONTROL_STRICT_PERMISSION` is set.
+#In particular, the scripts should have the proper executable
 #flag prior to the generation of the package.
-
+#
+# .. variable:: CPACK_DEBIAN_PACKAGE_CONTROL_STRICT_PERMISSION
+#   CPACK_DEBIAN__PACKAGE_CONTROL_STRICT_PERMISSION
+#
+#  This variable indicates if the Debian policy on control files should be
+#  strictly followed.
+#
+#  * Mandatory : NO
+#  * Default   : FALSE
+#
+#  Usage::
+#
+#   set(CPACK_DEBIAN_PACKAGE_CONTROL_STRICT_PERMISSION TRUE)
+#
+#  .. note::
+#
+#This overrides the permissions on the original files, following the rules
+#set by Debian policy
+#
https://www.debian.org/doc/debian-policy/ch-files.html#s-permissions-owners
+#
 
 #=
 # Copyright 2007-2009 Kitware, Inc.
@@ -636,7 +657,7 @@ function(cpack_deb_prepare_package_vars)
   # Are we packaging components ?
   if(CPACK_DEB_PACKAGE_COMPONENT)
 # override values with per component version if set
-foreach(VAR_NAME_ "PACKAGE_CONTROL_EXTRA")
+foreach(VAR_NAME_ "PACKAGE_CONTROL_EXTRA" 
"PACKAGE_CONTROL_STRICT_PERMISSION")
   if(CPACK_DEBIAN_${_local_component_name}_${VAR_NAME_})
 set(CPACK_DEBIAN_${VAR_NAME_} 
"${CPACK_DEBIAN_${_local_component_name}_${VAR_NAME_}}")
   endif()
@@ -658,6 +679,7 @@ function(cpack_deb_prepare_package_vars)
  message("CPackDeb:Debug: CPACK_PACKAGE_FILE_NAME   = 
${CPACK_PACKAGE_FILE_NAME}")
  message("CPackDeb:Debug: CPACK_PACKAGE_INSTALL_DIRECTORY   = 
${CPACK_PACKAGE_INSTALL_DIRECTORY}")
  message("CPackDeb:Debug: CPACK_TEMPORARY_PACKAGE_FILE_NAME = 
${CPACK_TEMPORARY_PACKAGE_FILE_NAME}")
+ message("CPackDeb:Debug: CPACK_DEBIAN_PACKAGE_CONTROL_STRICT_PERMISSION = 
${CPACK_DEBIAN_PACKAGE_CONTROL_STRICT_PERMISSION}")
   endif()
 
   # For debian source packages:
@@ -694,6 +716,8 @@ function(cpack_deb_prepare_package_vars)
   set(GEN_CPACK_DEBIAN_PACKAGE_PROVIDES "${CPACK_DEBIAN_PACKAGE_PROVIDES}" 
PARENT_SCOPE)
   set(GEN_CPACK_DEBIAN_PACKAGE_REPLACES "${CPACK_DEBIAN_PACKAGE_REPLACES}" 
PARENT_SCOPE)
   set(GEN_CPACK_DEBIAN_PACKAGE_CONTROL_EXTRA 
"${CPACK_DEBIAN_PACKAGE_CONTROL_EXTRA}" PARENT_SCOPE)
+  set(GEN_CPACK_DEBIAN_PACKAGE_CONTROL_STRICT_PERMISSION
+  "${CPACK_DEBIAN_PACKAGE_CONTROL_STRICT_PERMISSION}" PARENT_SCOPE)
   set(GEN_WDIR "${WDIR}" PARENT_SCOPE)
 endfunction()
 
diff --git a/Source/CPack/cmCPackDebGenerator.cxx 
b/Source/CPack/cmCPackDebGenerator.cxx
index 981d86d..b497b65 100644
--- a/Source/CPack/cmCPackDebGenerator.cxx
+++ b/Source/CPack/cmCPackDebGenerator.cxx
@@ -576,9 +576,18 @@ int cmCPackDebGenerator::createDeb()
 control_tar.SetUNAME("root");
 control_tar.SetGNAME("root");
 
-// set md5sum file permissions to RW-R--R-- so that deb lintian
-// doesn't warn about it
-control_tar.SetPermissions(S_IRUSR | S_IWUSR | S_I

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

[Raffi Enficiaud]

Hi Brad and Domen and others,

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

It is based on my previous patch.

Thanks,
Raffi
From 780a58a38d0445d1b4b58363b734a262a07a879e Mon Sep 17 00:00:00 2001
From: Raffi Enficiaud <raffi.enfici...@mines-paris.org>
Date: Mon, 14 Sep 2015 14:45:12 +0200
Subject: [PATCH] CPackDeb: preventing md5sum on symlinks

- Direct call to cmSystemTools::ComputeFileMD5
- Avoiding hashing symlinks
- Tests
---
 Source/CPack/cmCPackDebGenerator.cxx   | 42 --
 Tests/CPackComponentsDEB/CMakeLists.txt| 20 +++
 ...yResult-components-lintian-dpkgdeb-checks.cmake | 34 ++
 .../CPackComponentsDEB/RunCPackVerifyResult.cmake  | 12 +--
 4 files changed, 86 insertions(+), 22 deletions(-)

diff --git a/Source/CPack/cmCPackDebGenerator.cxx 
b/Source/CPack/cmCPackDebGenerator.cxx
index 981d86d..090c076 100644
--- a/Source/CPack/cmCPackDebGenerator.cxx
+++ b/Source/CPack/cmCPackDebGenerator.cxx
@@ -526,27 +526,31 @@ int cmCPackDebGenerator::createDeb()
packageFiles.begin();
  fileIt != packageFiles.end(); ++ fileIt )
   {
-  std::string cmd = "\"";
-  cmd += cmSystemTools::GetCMakeCommand();
-  cmd += "\" -E md5sum \"";
-  cmd += *fileIt;
-  cmd += "\"";
-
-  std::string output;
-  int retval = -1;
-  int res = cmSystemTools::RunSingleCommand(cmd.c_str(), , ,
-  , toplevel.c_str(), this->GeneratorVerbose, 0);
-  if ( !res || retval )
+
+// hash only regular files
+if(   cmSystemTools::FileIsDirectory(*fileIt)
+   || cmSystemTools::FileIsSymlink(*fileIt))
 {
-cmCPackLogger(cmCPackLog::LOG_ERROR, "Problem running cmake -E md5sum "
-  << cmd << std::endl);
+  continue;
 }
-  // debian md5sums entries are like this:
-  // 014f3604694729f3bf19263bac599765  usr/bin/ccmake
-  // thus strip the full path (with the trailing slash)
-  cmSystemTools::ReplaceString(output,
-   topLevelWithTrailingSlash.c_str(), "");
-  out << output;
+
+char md5sum[33];
+if(!cmSystemTools::ComputeFileMD5(*fileIt, md5sum))
+{
+  cmCPackLogger(cmCPackLog::LOG_ERROR, "Problem computing the md5 of "
+<< *fileIt << std::endl);
+}
+
+md5sum[32] = 0;
+
+std::string output(md5sum);
+output += "  " + *fileIt + "\n";
+// debian md5sums entries are like this:
+// 014f3604694729f3bf19263bac599765  usr/bin/ccmake
+// thus strip the full path (with the trailing slash)
+cmSystemTools::ReplaceString(output,
+ topLevelWithTrailingSlash.c_str(), "");
+out << output;
   }
 // each line contains a eol.
 // Do not end the md5sum file with yet another (invalid)
diff --git a/Tests/CPackComponentsDEB/CMakeLists.txt 
b/Tests/CPackComponentsDEB/CMakeLists.txt
index c25e33a..8ed81ac 100644
--- a/Tests/CPackComponentsDEB/CMakeLists.txt
+++ b/Tests/CPackComponentsDEB/CMakeLists.txt
@@ -93,6 +93,26 @@ if(CHMOD_PROG)
   "${CMAKE_CURRENT_BINARY_DIR}/preinst;${CMAKE_CURRENT_BINARY_DIR}/prerm")
 endif()
 
+# creates a symbolic link and a directory. Those should not be hashed.
+# warning: relocation of the symlink is not supported (symlinks with relative
+# paths)
+execute_process(COMMAND ${CMAKE_COMMAND} -E create_symlink mylibapp symtest)
+install(FILES ${CPackComponentsDEB_BINARY_DIR}/symtest
+DESTINATION bin
+COMPONENT applications)
+
+if(EXISTS "./dirtest")
+  execute_process(COMMAND ${CMAKE_COMMAND} -E remove_directory ./dirtest)
+endif()
+execute_process(COMMAND ${CMAKE_COMMAND} -E make_directory ./dirtest)
+# BUG: apparently cannot add an empty directory
+execute_process(COMMAND ${CMAKE_COMMAND} -E create_symlink ../mylibapp 
./dirtest/symtest)
+# NOTE: we should not add the trailing "/" to dirtest
+install(DIRECTORY ${CPackComponentsDEB_BINARY_DIR}/dirtest
+DESTINATION bin/
+COMPONENT applications)
+
+
 
 # We may use the CPack specific config file in order
 # to tailor CPack behavior on a CPack generator specific way
diff --git 
a/Tests/CPackComponentsDEB/RunCPackVerifyResult-components-lintian-dpkgdeb-checks.cmake
 
b/Tests/CPackComponentsDEB/RunCPackVerifyResult-components-lintian-dpkgdeb-checks.cmake
index 5460b1a..c2b2417 100644
--- 
a/Tests/CPackComponentsDEB/RunCPackVerifyResult-components-lintian-dpkgdeb-checks.cmake
+++ 
b/Tests/CPackComponentsDEB/RunCPackVerifyResult-components-

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

[Raffi Enficiaud]

Le 14/09/15 11:51, Raffi Enficiaud a écrit :

Hi Brad and Domen and others,

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.

Best,
Raffi



It's better with the attachment, sorry.

Raffi

>From 45fa572012ae2140a8b81d56c8d4b0b10e30c19f Mon Sep 17 00:00:00 2001
From: Raffi Enficiaud <raffi.enfici...@mines-paris.org>
Date: Mon, 14 Sep 2015 11:42:33 +0200
Subject: [PATCH] cpackdeb: reset extra file permissions to their original

Adding a note about the file permissions on the extra files.
---
 Modules/CPackDeb.cmake  |  7 ++-
 Source/CPack/cmCPackDebGenerator.cxx|  4 +++-
 Tests/CPackComponentsDEB/CMakeLists.txt | 14 ++
 3 files changed, 23 insertions(+), 2 deletions(-)

diff --git a/Modules/CPackDeb.cmake b/Modules/CPackDeb.cmake
index 970a7d0..0ccfee4 100644
--- a/Modules/CPackDeb.cmake
+++ b/Modules/CPackDeb.cmake
@@ -326,7 +326,12 @@
 #
 #   set(CPACK_DEBIAN_PACKAGE_CONTROL_EXTRA
 #   "${CMAKE_CURRENT_SOURCE_DIR/prerm;${CMAKE_CURRENT_SOURCE_DIR}/postrm")
-
+#
+#  .. note::
+#
+#The original permissions of the files will be used in the final
+#package. In particular, the scripts should have the proper executable
+#flag prior to the generation of the package.
 
 #=
 # Copyright 2007-2009 Kitware, Inc.
diff --git a/Source/CPack/cmCPackDebGenerator.cxx 
b/Source/CPack/cmCPackDebGenerator.cxx
index dc9fca3..981d86d 100644
--- a/Source/CPack/cmCPackDebGenerator.cxx
+++ b/Source/CPack/cmCPackDebGenerator.cxx
@@ -576,7 +576,7 @@ int cmCPackDebGenerator::createDeb()
 control_tar.SetUNAME("root");
 control_tar.SetGNAME("root");
 
-// set md5sum file permissins to RW-R--R-- so that deb lintian
+// set md5sum file permissions to RW-R--R-- so that deb lintian
 // doesn't warn about it
 control_tar.SetPermissions(S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH);
 
@@ -597,6 +597,8 @@ int cmCPackDebGenerator::createDeb()
   this->GetOption("GEN_CPACK_DEBIAN_PACKAGE_CONTROL_EXTRA");
 if( controlExtra )
   {
+  // permissions are now controlled by the original file permissions
+  control_tar.SetPermissions(-1);
   std::vector controlExtraList;
   cmSystemTools::ExpandListArgument(controlExtra, controlExtraList);
   for(std::vector::iterator i = controlExtraList.begin();
diff --git a/Tests/CPackComponentsDEB/CMakeLists.txt 
b/Tests/CPackComponentsDEB/CMakeLists.txt
index 5c4eeab..c25e33a 100644
--- a/Tests/CPackComponentsDEB/CMakeLists.txt
+++ b/Tests/CPackComponentsDEB/CMakeLists.txt
@@ -80,6 +80,20 @@ set(CPACK_COMPONENT_HEADERS_DESCRIPTION
 # depend on the libraries component.
 set(CPACK_COMPONENT_HEADERS_DEPENDS libraries)
 
+# creates preinst/prerm scripts with specific permissions. Those permissions
+# (especially executable) should be in the final archive
+find_program(CHMOD_PROG chmod)
+if(CHMOD_PROG)
+  file(WRITE ${CMAKE_CURRENT_BINARY_DIR}/preinst "echo default_preinst")
+  file(WRITE ${CMAKE_CURRENT_BINARY_DIR}/prerm "echo default_prerm")
+  execute_process(COMMAND ${CHMOD_PROG} a+x 
${CMAKE_CURRENT_BINARY_DIR}/preinst)
+  execute_process(COMMAND ${CHMOD_PROG} a+x ${CMAKE_CURRENT_BINARY_DIR}/prerm)
+
+  set(CPACK_DEBIAN_APPLICATIONS_PACKAGE_CONTROL_EXTRA
+  "${CMAKE_CURRENT_BINARY_DIR}/preinst;${CMAKE_CURRENT_BINARY_DIR}/prerm")
+endif()
+
+
 # We may use the CPack specific config file in order
 # to tailor CPack behavior on a CPack generator specific way
 # (Behavior would be different for RPM or TGZ or DEB ...)
-- 
1.9.1

-- 

Powered by www.kitware.com

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

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

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

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

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

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

[Raffi Enficiaud]

Hi Brad and Domen and others,

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?

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

From 96a0b35d408f8c0d9310eb753e95ed5d1f37424e Mon Sep 17 00:00:00 2001
From: Raffi Enficiaud <raffi.enfici...@mines-paris.org>
Date: Mon, 14 Sep 2015 15:25:50 +0200
Subject: [PATCH] CPackDeb: enables empty directories in packages

---
 Source/CPack/cmCPackDebGenerator.cxx| 2 ++
 Tests/CPackComponentsDEB/CMakeLists.txt | 3 +--
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/Source/CPack/cmCPackDebGenerator.cxx 
b/Source/CPack/cmCPackDebGenerator.cxx
index 090c076..3c2189f 100644
--- a/Source/CPack/cmCPackDebGenerator.cxx
+++ b/Source/CPack/cmCPackDebGenerator.cxx
@@ -95,6 +95,7 @@ int cmCPackDebGenerator::PackageOnePack(std::string 
initialTopLevel,
   std::string findExpr(this->GetOption("GEN_WDIR"));
   findExpr += "/*";
   gl.RecurseOn();
+  gl.SetRecurseListDirs(true);
   if ( !gl.FindFiles(findExpr) )
 {
 cmCPackLogger(cmCPackLog::LOG_ERROR,
@@ -222,6 +223,7 @@ int cmCPackDebGenerator::PackageComponentsAllInOne()
   std::string findExpr(this->GetOption("GEN_WDIR"));
   findExpr += "/*";
   gl.RecurseOn();
+  gl.SetRecurseListDirs(true);
   if ( !gl.FindFiles(findExpr) )
 {
 cmCPackLogger(cmCPackLog::LOG_ERROR,
diff --git a/Tests/CPackComponentsDEB/CMakeLists.txt 
b/Tests/CPackComponentsDEB/CMakeLists.txt
index 8ed81ac..d4bd9f1 100644
--- a/Tests/CPackComponentsDEB/CMakeLists.txt
+++ b/Tests/CPackComponentsDEB/CMakeLists.txt
@@ -104,9 +104,8 @@ install(FILES ${CPackComponentsDEB_BINARY_DIR}/symtest
 if(EXISTS "./dirtest")
   execute_process(COMMAND ${CMAKE_COMMAND} -E remove_directory ./dirtest)
 endif()
+# NOTE: directory left empty on purpose
 execute_process(COMMAND ${CMAKE_COMMAND} -E make_directory ./dirtest)
-# BUG: apparently cannot add an empty directory
-execute_process(COMMAND ${CMAKE_COMMAND} -E create_symlink ../mylibapp 
./dirtest/symtest)
 # NOTE: we should not add the trailing "/" to dirtest
 install(DIRECTORY ${CPackComponentsDEB_BINARY_DIR}/dirtest
 DESTINATION bin/
-- 
1.9.1

-- 

Powered by www.kitware.com

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

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

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

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

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

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

[Raffi Enficiaud]

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?

Raffi



--

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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

[Raffi Enficiaud]

Hi Domen,

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


Best and thanks,
Raffi

Le 14/09/15 23:19, Domen Vrankar a écrit :

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

[Raffi Enficiaud]

Le 11/09/15 21:34, Domen Vrankar a écrit :

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


Many thanks, Domen!



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


Should do, I will monitor the test this week end.



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.



You're right, files in data.tar.xx should not have their permission 
changed from the install command, and having uid/gid root/root should 
not be any different from the behaviour we have now with fakeroot. So I 
am perfectly fine with your changes, thank you!



Is it on time for 3.4 freeze?


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


Good!

Cheers,
Raffi

--

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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] [CPackDeb][libarchive] removing use of fakeroot and supporting UID/GID/UNAME etc in libarchive

[Raffi Enficiaud]

Hi Brad and Domen,

This is a follow up of the following thread

http://public.kitware.com/pipermail/cmake-developers/2015-August/026125.html

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

Please review the patches (mainly 2, the other one is just a typo fix).
Or if you prefer I can just create a topic. The patches are based on 
master and are quite orthogonal.


Is it on time for 3.4 freeze?

Thanks!
Raffi
From 2f12e427c4ffe238fbf79d7c317c90b4d9c3131f Mon Sep 17 00:00:00 2001
From: Raffi Enficiaud <raffi.enfici...@mines-paris.org>
Date: Tue, 8 Sep 2015 23:09:01 +0200
Subject: [PATCH 1/3] Various typo fixes RunCMake.CPack: Making the error
 message somehow more readable

---
 Source/cmGeneratedFileStream.h  | 4 ++--
 Tests/RunCMake/CPack/DEB/Helpers.cmake  | 2 +-
 Tests/RunCMake/CPack/README.txt | 4 ++--
 Tests/RunCMake/CPack/VerifyResult.cmake | 7 ---
 4 files changed, 9 insertions(+), 8 deletions(-)

diff --git a/Source/cmGeneratedFileStream.h b/Source/cmGeneratedFileStream.h
index 2aa6beb..8df3e1a 100644
--- a/Source/cmGeneratedFileStream.h
+++ b/Source/cmGeneratedFileStream.h
@@ -56,10 +56,10 @@ protected:
   // Whether the real file stream was valid when it was closed.
   bool Okay;
 
-  // Whether the destionation file is compressed
+  // Whether the destination file is compressed
   bool Compress;
 
-  // Whether the destionation file is compressed
+  // Whether the destination file is compressed
   bool CompressExtraExtension;
 };
 
diff --git a/Tests/RunCMake/CPack/DEB/Helpers.cmake 
b/Tests/RunCMake/CPack/DEB/Helpers.cmake
index a204a3c..b6f113b 100644
--- a/Tests/RunCMake/CPack/DEB/Helpers.cmake
+++ b/Tests/RunCMake/CPack/DEB/Helpers.cmake
@@ -14,7 +14,7 @@ function(verifyDebControl FILE PREFIX VERIFY_FILES)
   ERROR_VARIABLE err_)
 
   if(err_)
-message(FATAL_ERROR "Debian controll verification failed for file: "
+message(FATAL_ERROR "Debian control verification failed for file: "
 "'${FILE}'; error output: '${err_}'")
   endif()
 
diff --git a/Tests/RunCMake/CPack/README.txt b/Tests/RunCMake/CPack/README.txt
index 365c737..ea68304 100644
--- a/Tests/RunCMake/CPack/README.txt
+++ b/Tests/RunCMake/CPack/README.txt
@@ -32,14 +32,14 @@ different types of packages. This script is placed into 
CPack test root
 directory even if it will be used for only one of the generators.
 
 If test will be used for multiple generators but some of them require some
-generator speciffic commands then those commands should be added to a separate
+generator specific commands then those commands should be added to a separate
 file that should be located in '/-specifics.cmake'
 in CPack test root directory.
 
 CPack execution phase:
 --
 
-Only exececutes CPack for content that was generated during CMake execution
+Only executes CPack for content that was generated during CMake execution
 phase.
 
 Verification of generated files:
diff --git a/Tests/RunCMake/CPack/VerifyResult.cmake 
b/Tests/RunCMake/CPack/VerifyResult.cmake
index 96efa9e..6eab531 100644
--- a/Tests/RunCMake/CPack/VerifyResult.cmake
+++ b/Tests/RunCMake/CPack/VerifyResult.cmake
@@ -28,8 +28,9 @@ if(NOT EXPECTED_FILES_COUNT EQUAL 0)
 
   if(NOT expected_content_list)
 message(FATAL_ERROR
-  "Unexpected file content for file No. '${file_no_}'!"
-  " Content: '${PACKAGE_CONTENT}'"
+  "Unexpected file content for file No. '${file_no_}'!\n"
+  " Content: '${PACKAGE_CONTENT}'\n\n"
+  " Expected: '${EXPECTED_FILE_CONTENT_${file_no_}}'"
   "${output_error_message}")
   endif()
 else()
@@ -56,7 +57,7 @@ if(NOT EXPECTED_FILES_COUNT EQUAL 0)
 "${output_error_message}")
   endif()
 
-  # sanity check that we didn't accidentaly list wrong files with our regular
+  # sanity check that we didn't accidentally list wrong files with our regular
   # expressions
   foreach(expected_ IN LISTS allFoundFiles_)
 list(FIND foundFiles_ "${expected_}" found_)
-- 
2.0.1

From ba086d51479b7d5d11652d3647e5f4775d0a4f7d Mon Sep 17 00:00:00 2001
From: Raffi Enficiaud <raffi.enfici...@mines-paris.org>
Date: Fri, 11 Sep 2015 16:00:28 +0200
Subject: [PATCH 2/3] cmArchiveWrite: user/group and permissions

- support for UID/GID and UNAME/GNAME
- support for permission and permission mask
- support for non-recursive folder adding
---
 Source/cmArchiveWrite.cxx | 45 ---
 Source/cmArchiveWrite.h   | 77 +--
 2 files changed, 115 insertions(+), 7 deletions(-)

diff --git a/Source/cmArchiveWrite.cxx b/Source/cmArchiveWrite.cxx
index 9f56324..a8fc85d 100644
--- a/Source/cmArchiveWrite.cxx
+++ b

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

[Raffi Enficiaud]

Le 26/08/15 01:07, Eric Noulard a écrit :


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


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

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


Ok, but the created packages are not debian compliant, so we cannot 
really say that the generated artifacts are Debian packages.




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



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.


Raffi


--

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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

[Raffi Enficiaud]

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

Hi guys,

Some of my thoughts about this one.


Hi,

thanks you for your quick reply!



2015-08-25 15:42 GMT+02:00 Raffi Enficiaud



[snip]

Yes but the may be interesting part should be in:
/«BUILDDIR»/build_dir/_CPack_Packages/Linux/DEB/Deb.log

which is not displayed in the previous file.


Sorry for that, I forgot to tell that everything works ok without 
pbuilder. So I believe this is the issue, I will check next time I build 
this.




Basically in my case, the debian/rule file calls cmake and cpack to
generate the deb packages.
pbuilder mimics a clean build environment that is used on Launchpad
for isolating the build, and I believe (not sure) it calls fakeroot
under the hood.


pbuilder calls fakeroot for sure:
In your log one can see:

make[1]: Leaving directory `/«BUILDDIR»/build_dir'
  fakeroot debian/rules binary-arch
touch debian/files
cpack --version
cpack version 3.3.20150824


[snip]

The introduction of fakeroot usage for CPackDeb was made for that issue:
http://public.kitware.com/Bug/view.php?id=10325
with the small follow-up you cited:
http://public.kitware.com/Bug/view.php?id=13118


Right, but again the main idea seems to be able to set the uid/guid 
properly in the tar.




fakeroot is not used unless it is detected as installed on the system.
The question in your case is, why is fakeroot installed AND not working
when used in pbuilder.

My guess is that pbuilder is ALREADY calling fakeroot and that fakeroot
cannot be called from within fakerootED environnement (nested fakeroot
is unsupported).


I also think this is the issue, nesting fakeroot is not supported.



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


I did not know about this key, that would be a nice/clean resolution to 
the problem.





The #13700 bugs referred hereafter confirms this kind of issue:
http://public.kitware.com/Bug/view.php?id=13700

- unifying the tool used for creating the tar: from the code in
cmCPackDebGenerator.cxx, some compression schemes use the native tar
while some others use the cmake tar.


This is explained in Source/CPack/cmCPackDebGenerator.cxx
// NOTE:
// A debian package .deb is simply an 'ar' archive. The only subtle
difference
// is that debian uses the BSD ar style archive whereas most Linux
distro have
// a GNU ar.
// See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=161593 for more info
// Therefore we provide our own implementation of a BSD-ar:
static int ar_append(const char*archive,const std::vectorstd::string
files);

I don't really known whether if this argument still apply nowadays
and I let you read the discussion on bugs.debian.org
http://bugs.debian.org.


Ok. Let's not burn our fingers on this direction then :)


What would be the best option for you?



I let Domen answer for that, I was just jumping in to let you all know
the bits of the story I remember.


I believe it would address this issues already in the backlog (and
help ppl deploy things on Launchpad with cmake):
- http://public.kitware.com/Bug/view.php?id=13700
- http://public.kitware.com/Bug/view.php?id=11766


Like I said 13700 should be easy to fix by avoiding nested fakeroot call.

11766 is another story.
I think that adding ownership option to cmake -E tar may be useful but
not that urgent considering
that most of these issues can be fixed in another easy mean.


If I understand the issue well, their concern
https://htcondor-wiki.cs.wisc.edu/index.cgi/tktview?tn=1863

was about doing some experiments for having root/root uid/guid + some 
fancy block size. root/root is ok now with fakeroot, and they abandoned 
the block_size fancy options.


The thing is that root/root implementation today is not fully ok due to 
the bug exposed on this thread (nested fakeroot).



That said libarchive now seems to support BSD tar
https://github.com/libarchive/libarchive/tree/master/tar
and ownership using set_ownership(struct archive_write_disk *) API.

so may be it's possible to get rid of the BSD tar implementation embedded in
cmCPackDebGenerator.cxx and add appropriate calls to libarchive.



That would be a solution, but it is hard for me to see the gain of 
touching that many files instead of having the nice FAKEROOTKEY detection.


Thanks again!
Raffi



--

Powered by www.kitware.com

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

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

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

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

[Raffi Enficiaud]

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

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


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


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

- or using a CPACK variable to avoid having fakeroot executed

I see several workarounds/hacks:
- executing with fakeroot in cpack first and in case of failure falling 
back to run tar without fakeroot

- detect if the current user is root already

Raffi

--

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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

[Raffi Enficiaud]

Le 26/08/15 00:45, Eric Noulard a écrit :

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


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


Sorry I wanted to say cross-packaging. Still I think using the system 
default tar program is a good way to go.



- or using a CPACK variable to avoid having fakeroot executed


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


I agree.



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


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



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


Raffi

--

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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] [CPack] CPackDeb and fakeroot

[Raffi Enficiaud]

Hi Domen, Brad and CMake developers,

I am trying to create my packages in Launchpad, which uses a pbuilder 
environment for building the packages, directly using CMake=3.3 (which 
contains the nice recent fixes).


I got the following error when I execute the build of a source package 
from pbuilder:



CPack Error: 
/build/cmake-AHTLnO/cmake-3.3travisci1/Source/CPack/cmCPackDebGenerator.cxx:483 
Problem running tar command: /usr/bin/fakeroot /usr/bin/cmake -E tar 
czf data.tar.gz
Please check /«BUILDDIR»/build_dir/_CPack_Packages/Linux/DEB/Deb.log for 
errors



The full logs for the curious ppl may be found here:
https://launchpadlibrarian.net/215456337/buildlog_ubuntu-trusty-amd64.yayi_0.8.8.1_BUILDING.txt.gz

Basically in my case, the debian/rule file calls cmake and cpack to 
generate the deb packages.
pbuilder mimics a clean build environment that is used on Launchpad for 
isolating the build, and I believe (not sure) it calls fakeroot under 
the hood.


To my understanding fakeroot is a workaround to have the proper 
credentials in the tar of the .deb packages since the libarchive used in 
cmake was not allowing that at that time:


- http://public.kitware.com/Bug/view.php?id=11766
- http://public.kitware.com/Bug/view.php?id=13118
- http://public.kitware.com/Bug/view.php?id=12901


I am wondering if, instead of always using fakeroot:
- there is now the possibility to set the user in libarchive (even if it 
is the case, this would mean that cmake -E tar is able to understand 
those options)
- if we can get rid of the fakeroot in some circumstances? eg. a 
variable that would avoid using the fakeroot or detecting that the user 
is already root
- unifying the tool used for creating the tar: from the code in 
cmCPackDebGenerator.cxx, some compression schemes use the native tar 
while some others use the cmake tar.


What would be the best option for you?

I believe it would address this issues already in the backlog (and help 
ppl deploy things on Launchpad with cmake):

- http://public.kitware.com/Bug/view.php?id=13700
- http://public.kitware.com/Bug/view.php?id=11766


Thanks for your feedbacks,
Best,
Raffi Enficiaud

--

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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] OSX - Application bundle and private frameworks?

[Raffi Enficiaud]

Hi,

I am trying to copy a private framework into an application bundle:

- I can find the frameworks properly with the find_library,
- I put those frameworks in the add_executable command

add_executable(

MACOSX_BUNDLE

### source files ...
### frameworks
${sbigudFramework}
${fcCamFramework}
)

target_link_libraries( [...] ${sbigudFramework} ${fcCamFramework})

- and I specify the location of those frameworks within the application 
bundle:


set_source_files_properties(${fcCamFramework}  PROPERTIES 
MACOSX_PACKAGE_LOCATION Frameworks)
set_source_files_properties(${sbigudFramework} PROPERTIES 
MACOSX_PACKAGE_LOCATION Frameworks)




The problem is the following:
- Everything works fine with XCode, I have the full content of the 
frameworks at the specified location
- When I use the Makefile generator, I have only one file per framework 
instead of the directory and the framework content:


 ls -al .app/Contents/Frameworks/
total 0
drwxr-xr-x  4 raffi  staff  136 Jul 14 00:26 .
drwxr-xr-x  6 raffi  staff  204 Jul 14 00:08 ..
-rwxr-xr-x  1 raffi  staff0 Jul 14 00:26 SBIGUDrv.framework
-rwxr-xr-x  1 raffi  staff0 Jul 14 00:26 fcCamFw.framework

Am I doing something wrong? I am using cmake 3.0.2  3.2.3 / OSX 10.10.

Best,
Raffi

--

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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-commits] CMake branch, next, updated. v3.2.2-3250-ge932b35

[Raffi Enficiaud]

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

The branch, next has been updated
   via  e932b3553022e6b023c40b0a207f3e16e409dd30 (commit)
   via  d1e4b3b68b6e948760360215b940d880cc5d6ce4 (commit)
   via  028945de180d4dabb37a49264b4aecad0cb26400 (commit)
  from  e9c8f66b3d7800d8db5129a666dcf9849c167ed1 (commit)

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

- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e932b3553022e6b023c40b0a207f3e16e409dd30
commit e932b3553022e6b023c40b0a207f3e16e409dd30
Merge: e9c8f66 d1e4b3b
Author: Raffi Enficiaud raffi.enfici...@mines-paris.org
AuthorDate: Fri May 29 11:48:57 2015 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Fri May 29 11:48:57 2015 -0400

Merge topic 'FindMatlab-fix-visibility-and-reconfiguration' into next

d1e4b3b6 FindMatlab: fix reconfiguration of Matlab_ROOT_DIR
028945de FindMatlab: fix header visibility of the generated mex files


http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d1e4b3b68b6e948760360215b940d880cc5d6ce4
commit d1e4b3b68b6e948760360215b940d880cc5d6ce4
Author: Raffi Enficiaud raffi.enfici...@mines-paris.org
AuthorDate: Fri May 29 17:44:19 2015 +0200
Commit: Raffi Enficiaud raffi.enfici...@mines-paris.org
CommitDate: Fri May 29 17:44:19 2015 +0200

FindMatlab: fix reconfiguration of Matlab_ROOT_DIR

diff --git a/Modules/FindMatlab.cmake b/Modules/FindMatlab.cmake
index 939f796..028bf5a 100644
--- a/Modules/FindMatlab.cmake
+++ b/Modules/FindMatlab.cmake
@@ -134,7 +134,8 @@
 #   returns the suffix to be used for the mex files
 #   (platform/architecture dependant)
 # :command:`matlab_get_version_from_matlab_run`
-#   returns the version of Matlab, given the full directory of the Matlab 
program.
+#   returns the version of Matlab, given the full directory of the Matlab
+#   program.
 #
 #
 # Known issues
@@ -1064,7 +1065,7 @@ if(Matlab_ROOT_DIR)
 endif()
   else()
 # NOTFOUND indicates the code below to search for the version automatically
-if(NOT DEFINED Matlab_VERSION_STRING_INTERNAL)
+if(${Matlab_VERSION_STRING_INTERNAL} STREQUAL )
   list(APPEND _matlab_possible_roots NOTFOUND ${Matlab_ROOT_DIR}) # 
empty version
 else()
   list(APPEND _matlab_possible_roots ${Matlab_VERSION_STRING_INTERNAL} 
${Matlab_ROOT_DIR}) # cached version
diff --git a/Tests/RunCMake/FindMatlab/MatlabTest2-result.txt 
b/Tests/RunCMake/FindMatlab/MatlabTest2-result.txt
new file mode 100644
index 000..573541a
--- /dev/null
+++ b/Tests/RunCMake/FindMatlab/MatlabTest2-result.txt
@@ -0,0 +1 @@
+0
diff --git a/Tests/RunCMake/FindMatlab/MatlabTest2-stderr.txt 
b/Tests/RunCMake/FindMatlab/MatlabTest2-stderr.txt
new file mode 100644
index 000..9abb766
--- /dev/null
+++ b/Tests/RunCMake/FindMatlab/MatlabTest2-stderr.txt
@@ -0,0 +1 @@
+.*
\ No newline at end of file
diff --git a/Tests/RunCMake/FindMatlab/MatlabTest2.cmake 
b/Tests/RunCMake/FindMatlab/MatlabTest2.cmake
new file mode 100644
index 000..d5b0e6d
--- /dev/null
+++ b/Tests/RunCMake/FindMatlab/MatlabTest2.cmake
@@ -0,0 +1,9 @@
+cmake_minimum_required (VERSION 2.8.12)
+enable_testing()
+project(findmatlab_runcmake_test2)
+
+if(NOT DEFINED matlab_required)
+  set(matlab_required REQUIRED)
+endif()
+
+find_package(Matlab ${matlab_required} COMPONENTS MX_LIBRARY)
diff --git a/Tests/RunCMake/FindMatlab/RunCMakeTest.cmake 
b/Tests/RunCMake/FindMatlab/RunCMakeTest.cmake
index 33dbb77..f0eb6b4 100644
--- a/Tests/RunCMake/FindMatlab/RunCMakeTest.cmake
+++ b/Tests/RunCMake/FindMatlab/RunCMakeTest.cmake
@@ -1,3 +1,51 @@
 
 include(RunCMake)
 run_cmake(MatlabTest1)
+
+if(RunCMake_GENERATOR MATCHES Make AND UNIX)
+  # Use a single build tree for a few tests without cleaning.
+  set(RunCMake_TEST_BINARY_DIR 
${RunCMake_BINARY_DIR}/RerunFindMatlab-build-init)
+  set(RunCMake_TEST_NO_CLEAN 1)
+  file(REMOVE_RECURSE ${RunCMake_TEST_BINARY_DIR})
+  file(MAKE_DIRECTORY ${RunCMake_TEST_BINARY_DIR})
+
+  message(STATUS RerunFindMatlab: first configuration to extract real 
Matlab_ROOT_DIR)
+  set(RunCMake_TEST_OPTIONS -Dmatlab_required=REQUIRED)
+  run_cmake(MatlabTest2)
+
+  message(STATUS RerunFindMatlab: flushing the variables)
+  execute_process(COMMAND
+${CMAKE_COMMAND} -L ${RunCMake_TEST_BINARY_DIR}
+RESULT_VARIABLE _MatlabTest2_error
+OUTPUT_VARIABLE _MatlabTest2_output)
+  if(NOT _MatlabTest2_error EQUAL 0)
+message(FATAL_ERROR RerunFindMatlab: cannot list the variables ...)
+  endif()
+
+  string(REGEX MATCH Matlab_ROOT_DIR.+=([^\r\n]+) _matched 
${_MatlabTest2_output})
+
+  set(Matlab_ROOT_DIR_correct ${CMAKE_MATCH_1})
+  if(Matlab_ROOT_DIR_correct STREQUAL

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

[Raffi Enficiaud]

Le 15/05/15 23:10, Domen Vrankar a écrit :

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



Hi Domen,

I do not know if those patches are in master, but after searching a bit 
in the bugtracker, I think the following issues are now addressed:


- 0013232: CPackDeb fails on dependency auto-gen if any component does 
not contain any ELF binaries
- 0013488: Patch for CPack Debian generator (fix to the auto-dependecy 
support via dpkg-shlibdeps)
- 0013231: CPackDeb incorrectly leaks Debian dependencies across 
components

- 0011944: CPackDeb: Support dependencies between components/Debian packages

The following is partially addressed:
- 0013386: CPack-generated Debian packages do not comply to Debian 
policy (discovered via lintian) -- missing eg. the license file error --


I do not know about
- 0013015: cpack deb generator components specify output names

Best,
Raffi

--

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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

[Raffi Enficiaud]

Le 09/05/15 12:14, Domen Vrankar a écrit :

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



Hi Domen,

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

Best,
Raffi

From f3cdd2e6c0d80d23da77fa9e5cc5cdce45270649 Mon Sep 17 00:00:00 2001
From: Raffi Enficiaud raffi.enfici...@tuebingen.mpg.de
Date: Mon, 11 May 2015 15:18:05 +0200
Subject: [PATCH] CPackDEB: reworked documentation

---
 Modules/CPackDeb.cmake | 155 +
 1 file changed, 106 insertions(+), 49 deletions(-)

diff --git a/Modules/CPackDeb.cmake b/Modules/CPackDeb.cmake
index 0ccb042..a30a07e 100644
--- a/Modules/CPackDeb.cmake
+++ b/Modules/CPackDeb.cmake
@@ -28,29 +28,33 @@
 #
 # .. variable:: CPACK_DEBIAN_PACKAGE_NAME
 #
+#  The Debian package summary
+#
 #  * Mandatory : YES
-#  * Default   : CPACK_PACKAGE_NAME (lower case)
+#  * Default   : :variable:`CPACK_PACKAGE_NAME` (lower case)
 #
-#  The debian package summary
 #
 # .. variable:: CPACK_DEBIAN_PACKAGE_VERSION
 #
+#  The Debian package version
+#
 #  * Mandatory : YES
-#  * Default   : CPACK_PACKAGE_VERSION
+#  * Default   : :variable:`CPACK_PACKAGE_VERSION`
 #
-#  The debian package version
 #
 # .. variable:: CPACK_DEBIAN_PACKAGE_ARCHITECTURE
 #
+#  The Debian package architecture
+#
 #  * Mandatory : YES
-#  * Default   : Output of dpkg --print-architecture (or i386 if dpkg is not 
found)
+#  * Default   : Output of :code:`dpkg --print-architecture` (or :code:`i386`
+#if :code:`dpkg` is not found)
 #
-#  The debian package architecture
 #
 # .. variable:: CPACK_DEBIAN_PACKAGE_DEPENDS
 #   CPACK_DEBIAN_COMPONENT_PACKAGE_DEPENDS
 #
-#  May be used to set deb dependencies.
+#  Sets the Debian dependencies of this package.
 #
 #  * Mandatory : NO
 #  * Default   :
@@ -64,7 +68,7 @@
 #If :variable:`CPACK_DEBIAN_PACKAGE_SHLIBDEPS` or
 #more specifically :variable:`CPACK_DEBIAN_COMPONENT_PACKAGE_SHLIBDEPS`
 #is set for this component, the discovered dependencies will be appended
-#to :variable:`CPACK_DEBIAN_COMPONENT_PACKAGE_DEPENDS` intead of
+#to :variable:`CPACK_DEBIAN_COMPONENT_PACKAGE_DEPENDS` instead of
 #:variable:`CPACK_DEBIAN_PACKAGE_DEPENDS`. If
 #:variable:`CPACK_DEBIAN_COMPONENT_PACKAGE_DEPENDS` is an empty string,
 #only the automatically discovered dependencies will be set for this
@@ -76,21 +80,25 @@
 #
 # .. variable:: CPACK_DEBIAN_PACKAGE_MAINTAINER
 #
+#  The Debian package maintainer
+#
 #  * Mandatory : YES
-#  * Default   : CPACK_PACKAGE_CONTACT
+#  * Default   : :code:`CPACK_PACKAGE_CONTACT`
 #
-#  The debian package maintainer
 #
 # .. variable:: CPACK_DEBIAN_PACKAGE_DESCRIPTION
 #   CPACK_COMPONENT_COMPONENT_DESCRIPTION
 #
-#  The debian package description
+#  The Debian package description
 #
 #  * Mandatory : YES
 #  * Default   :
 #
-#- :variable:`CPACK_DEBIAN_PACKAGE_DESCRIPTION` if set or
-#- :variable:`CPACK_PACKAGE_DESCRIPTION_SUMMARY`
+#- :variable:`CPACK_PACKAGE_DESCRIPTION_SUMMARY` for non-component based
+#  installation
+#- :variable:`CPACK_DEBIAN_PACKAGE_DESCRIPTION` for component-based
+#  installation
+#
 #
 # .. variable:: CPACK_DEBIAN_PACKAGE_SECTION
 #
@@ -99,33 +107,40 @@
 #
 # .. variable:: CPACK_DEBIAN_COMPRESSION_TYPE
 #
+#  The compression used for creating the Debian package.
+#  Possible values are: lzma, xz, bzip2 and gzip.
+#
 #  * Mandatory : YES
 #  * Default   : 'gzip'
 #
-# Possible values are: lzma, xz, bzip2 and gzip.
 #
 # .. variable:: CPACK_DEBIAN_PACKAGE_PRIORITY
 #
+#  The Debian package priority
+#
 #  * Mandatory : YES
 #  * Default   : 'optional'
 #
-#  The debian package priority
 #
 # .. variable:: CPACK_DEBIAN_PACKAGE_HOMEPAGE
 #
-#  * Mandatory : NO
-#  * Default   : -
-#
 #  The URL of the web site for this package, preferably (when applicable) the
 #  site from which the original source can be obtained and any additional
 #  upstream documentation or information may be found.
-#  The content of this field is a simple URL without any surrounding
-#  characters such as .
+#
+#  * Mandatory : NO
+#  * Default   : -
+#
+#  .. note::
+#
+#The content of this field is a simple URL without any surrounding
+#characters such as .
+#
 #
 # .. variable:: CPACK_DEBIAN_PACKAGE_SHLIBDEPS
 #   CPACK_DEBIAN_COMPONENT_PACKAGE_SHLIBDEPS
 #
-#  May be set to ON in order to use dpkg-shlibdeps to generate
+#  May be set to ON in order to use :code:`dpkg-shlibdeps` to generate
 #  better package dependency list.
 #
 #  * Mandatory : NO
@@ -141,92 +156,132 @@
 #may fail to find your own shared libs.
 #See http://www.cmake.org/Wiki/CMake_RPATH_handling.
 #
-# .. variable:: CPACK_DEBIAN_PACKAGE_DEBUG
 #
-#  * Mandatory : NO
-#  * Default   : -
+# .. variable:: CPACK_DEBIAN_PACKAGE_DEBUG
 #
 #  May be set when invoking cpack in order to trace debug information
 #  during CPackDeb run.
 #
+#  * Mandatory

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

[Raffi Enficiaud]

Le 08/05/15 07:54, Domen Vrankar a écrit :

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.


Sorry I forgot about this...

Attached is verbose output and patch that I was using (slightly
modified patch that you provided rebased to current master).



Hi,

Thanks, I will have a look this afternoon (sorry for the delay),

Raffi


--

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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

[Raffi Enficiaud]

Le 08/05/15 07:54, Domen Vrankar a écrit :

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.


Sorry I forgot about this...

Attached is verbose output and patch that I was using (slightly
modified patch that you provided rebased to current master).



Hi,

In fact, CPACK_DEBIAN_PACKAGE_DEBUG ON does not produce the desired 
effect. The messages executed inside the CPackDeb.cmake are redirected 
for some reason to the error stream.


Would you please add the following to line 61, file 
RunCPackVerifyResult.cmake


message(STATUS CPack_error=${CPack_error})

It also looks like the definition of the 
CPACK_DEBIAN_APPLICATIONS_PACKAGE_DEPENDS (equals to an empty string in 
the test) has precedence over the shlibdeps output.


Thanks,
Raffi

--

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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

[Raffi Enficiaud]

-headers)
+  if(NOT ${dpkg_depends} STREQUAL depend-headers)
+set(dpkgdeb_output_errors_all ${dpkgdeb_output_errors_all}
+  dpkg-deb: ${_f}: Incorrect dependencies 
for package ${dpkg_package_name}: '${dpkg_depends}' != 'depend-headers'\n)
+  endif()
+elseif(${dpkg_package_name} STREQUAL mylib-libraries)
+  if(NOT ${dpkg_depends} STREQUAL depend-default)
+set(dpkgdeb_output_errors_all ${dpkgdeb_output_errors_all}
+  dpkg-deb: ${_f}: Incorrect dependencies 
for package ${dpkg_package_name}: '${dpkg_depends}' != 'depend-default'\n)
+  endif()
+else()
+  set(dpkgdeb_output_errors_all ${dpkgdeb_output_errors_all}
+dpkg-deb: ${_f}: component name not 
found: ${dpkg_package_name}\n)
+endif()
+
+  endforeach()
+
+  if(NOT ${dpkgdeb_output_errors_all} STREQUAL )
+message(FATAL_ERROR dpkg-deb checks 
failed:\n${dpkgdeb_output_errors_all})
+  endif()
+else()
+  message(dpkg-deb executable not found - skipping dpkg-deb test)
+endif()
-- 
1.9.4.msysgit.2

From 9f1f66ee4b811f19e827271e45d8356588d24629 Mon Sep 17 00:00:00 2001
From: Raffi Enficiaud raffi.enfici...@free.fr
Date: Fri, 8 May 2015 20:44:25 +0200
Subject: [PATCH 2/4] CPackDEB: getting the logs from the DEBUG traces as well

---
 Tests/CPackComponentsDEB/RunCPackVerifyResult.cmake | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Tests/CPackComponentsDEB/RunCPackVerifyResult.cmake 
b/Tests/CPackComponentsDEB/RunCPackVerifyResult.cmake
index bd4f12a..b96669e 100644
--- a/Tests/CPackComponentsDEB/RunCPackVerifyResult.cmake
+++ b/Tests/CPackComponentsDEB/RunCPackVerifyResult.cmake
@@ -58,6 +58,7 @@ function(run_cpack output_expected_file CPack_output_parent 
CPack_error_parent)
 message(FATAL_ERROR error: CPack execution went wrong!, 
CPack_output=${CPack_output}, CPack_error=${CPack_error})
   else ()
 message(STATUS CPack_output=${CPack_output})
+message(STATUS CPack_error=${CPack_error})
   endif()
 
 
-- 
1.9.4.msysgit.2

From 12477a5b63e56efa2d6476bad5815308cd1aa8b8 Mon Sep 17 00:00:00 2001
From: Raffi Enficiaud raffi.enfici...@free.fr
Date: Fri, 8 May 2015 21:05:32 +0200
Subject: [PATCH 3/4] CPackDEB: More information on the outputs

---
 Modules/CPackDeb.cmake | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/Modules/CPackDeb.cmake b/Modules/CPackDeb.cmake
index a2e37c0..060c5af 100644
--- a/Modules/CPackDeb.cmake
+++ b/Modules/CPackDeb.cmake
@@ -370,7 +370,7 @@ function(cpack_deb_prepare_package_vars)
 string(REGEX REPLACE ^.*Depends=  
CPACK_DEBIAN_PACKAGE_AUTO_DEPENDS ${SHLIBDEPS_OUTPUT})
 
 if(CPACK_DEBIAN_PACKAGE_DEBUG)
-  message( CPackDeb Debug: Found dependency: 
${CPACK_DEBIAN_PACKAGE_AUTO_DEPENDS})
+  message( CPackDeb Debug: Found dependency: 
${CPACK_DEBIAN_PACKAGE_AUTO_DEPENDS} from output ${SHLIBDEPS_OUTPUT})
 endif()
 
 # Remove blank control file
@@ -451,8 +451,8 @@ function(cpack_deb_prepare_package_vars)
 
   # at this point, the CPACK_DEBIAN_PACKAGE_DEPENDS is properly set
   # to the minimal dependency of the package
-  # Append automatic dependance discovery.
-  if(CPACK_DEBIAN_PACKAGE_AUTO_DEPENDS AND NOT 
CPACK_DEBIAN_PACKAGE_AUTO_DEPENDS STREQUAL )
+  # Append automatically discovered dependencies .
+  if(NOT ${CPACK_DEBIAN_PACKAGE_AUTO_DEPENDS} STREQUAL )
 if (CPACK_DEBIAN_PACKAGE_DEPENDS)
   set (CPACK_DEBIAN_PACKAGE_DEPENDS ${CPACK_DEBIAN_PACKAGE_AUTO_DEPENDS}, 
${CPACK_DEBIAN_PACKAGE_DEPENDS})
 else ()
-- 
1.9.4.msysgit.2

From 8c33eb4ad0e6b4eb02ca0439aeecaca5081c1969 Mon Sep 17 00:00:00 2001
From: Raffi Enficiaud raffi.enfici...@free.fr
Date: Fri, 8 May 2015 21:19:27 +0200
Subject: [PATCH 4/4] CPackDEB: fixup! dependencies per component

---
 Modules/CPackDeb.cmake | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Modules/CPackDeb.cmake b/Modules/CPackDeb.cmake
index 060c5af..7f5be0f 100644
--- a/Modules/CPackDeb.cmake
+++ b/Modules/CPackDeb.cmake
@@ -441,7 +441,7 @@ function(cpack_deb_prepare_package_vars)
 set(_component_depends_var 
CPACK_DEBIAN_${_local_component_name}_PACKAGE_DEPENDS)
 
 # if set, overrides the global dependency
-if(DEFINED ${_component_depends_var})
+if(DEFINED ${_component_depends_var})
   set(CPACK_DEBIAN_PACKAGE_DEPENDS ${${_component_depends_var}})
   if(CPACK_DEBIAN_PACKAGE_DEBUG)
 message(CPackDeb Debug: component '${_local_component_name}' 
dependencies set to '${CPACK_DEBIAN_PACKAGE_DEPENDS}')
-- 
1.9.4.msysgit.2

-- 

Powered by www.kitware.com

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

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

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

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

[Raffi Enficiaud]

Le 02/05/15 22:19, Domen Vrankar a écrit :

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



Hi,

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?


Best,
Raffi

--

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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

[Raffi Enficiaud]

Le 28/04/15 12:23, Domen Vrankar a écrit :

Hi,

Sorry for not replying sooner.



Attachement ...

From b1e65486c99ff1023310e3c42fd509fc22e0575d Mon Sep 17 00:00:00 2001
From: Raffi Enficiaud raffi.enfici...@mines-paris.org
Date: Wed, 29 Apr 2015 16:43:50 +0200
Subject: [PATCH] CPackDEB: adding support for description per component

---
 Modules/CPackDeb.cmake | 38 --
 Tests/CMakeLists.txt   |  4 +-
 ...LibCPackConfig-components-description1.cmake.in | 25 +++
 ...LibCPackConfig-components-description2.cmake.in | 29 
 ...CPackVerifyResult-components-description1.cmake | 85 ++
 ...CPackVerifyResult-components-description2.cmake | 85 ++
 6 files changed, 259 insertions(+), 7 deletions(-)
 create mode 100644 
Tests/CPackComponentsDEB/MyLibCPackConfig-components-description1.cmake.in
 create mode 100644 
Tests/CPackComponentsDEB/MyLibCPackConfig-components-description2.cmake.in
 create mode 100644 
Tests/CPackComponentsDEB/RunCPackVerifyResult-components-description1.cmake
 create mode 100644 
Tests/CPackComponentsDEB/RunCPackVerifyResult-components-description2.cmake

diff --git a/Modules/CPackDeb.cmake b/Modules/CPackDeb.cmake
index f248a67..c146e3b 100644
--- a/Modules/CPackDeb.cmake
+++ b/Modules/CPackDeb.cmake
@@ -56,11 +56,18 @@
 #  The debian package maintainer
 #
 # .. variable:: CPACK_DEBIAN_PACKAGE_DESCRIPTION
+#   CPACK_COMPONENT_COMP_DESCRIPTION
+#
+#  The debian package description
 #
 #  * Mandatory : YES
-#  * Default   : CPACK_PACKAGE_DESCRIPTION_SUMMARY
+#  * Default   :
+#
+#- :variable:`CPACK_PACKAGE_DESCRIPTION_SUMMARY` for non-component based
+#  installation
+#- :variable:`CPACK_DEBIAN_PACKAGE_DESCRIPTION` for component-based
+#  installation
 #
-#  The debian package description
 #
 # .. variable:: CPACK_DEBIAN_PACKAGE_SECTION
 #
@@ -379,11 +386,30 @@ function(cpack_deb_prepare_package_vars)
   endif()
 
   # Description: (mandatory)
-  if(NOT CPACK_DEBIAN_PACKAGE_DESCRIPTION)
-if(NOT CPACK_PACKAGE_DESCRIPTION_SUMMARY)
-  message(FATAL_ERROR CPackDeb: Debian package requires a summary for a 
package, set CPACK_PACKAGE_DESCRIPTION_SUMMARY or 
CPACK_DEBIAN_PACKAGE_DESCRIPTION)
+  if(NOT CPACK_DEB_PACKAGE_COMPONENT)
+if(NOT CPACK_DEBIAN_PACKAGE_DESCRIPTION)
+  if(NOT CPACK_PACKAGE_DESCRIPTION_SUMMARY)
+message(FATAL_ERROR CPackDeb: Debian package requires a summary for a 
package, set CPACK_PACKAGE_DESCRIPTION_SUMMARY or 
CPACK_DEBIAN_PACKAGE_DESCRIPTION)
+  endif()
+  set(CPACK_DEBIAN_PACKAGE_DESCRIPTION 
${CPACK_PACKAGE_DESCRIPTION_SUMMARY})
+endif()
+  else()
+string(TOUPPER ${CPACK_DEB_PACKAGE_COMPONENT} _local_component_name)
+set(component_description_var 
CPACK_COMPONENT_${_local_component_name}_DESCRIPTION)
+
+# component description overrides package description
+if(${component_description_var})
+  set(CPACK_DEBIAN_PACKAGE_DESCRIPTION ${${component_description_var}})
+elseif(CPACK_DEBIAN_PACKAGE_DESCRIPTION)
+  # do nothing
+else()
+  if(NOT CPACK_PACKAGE_DESCRIPTION_SUMMARY)
+message(FATAL_ERROR CPackDeb: Debian package requires a summary for a 
package, set CPACK_PACKAGE_DESCRIPTION_SUMMARY or 
CPACK_DEBIAN_PACKAGE_DESCRIPTION
+ or ${component_description_var})
+  endif()
+  set(CPACK_DEBIAN_PACKAGE_DESCRIPTION 
${CPACK_PACKAGE_DESCRIPTION_SUMMARY})
 endif()
-set(CPACK_DEBIAN_PACKAGE_DESCRIPTION ${CPACK_PACKAGE_DESCRIPTION_SUMMARY})
+  
   endif()
 
   # Section: (recommended)
diff --git a/Tests/CMakeLists.txt b/Tests/CMakeLists.txt
index f1379e6..3a7c16b 100644
--- a/Tests/CMakeLists.txt
+++ b/Tests/CMakeLists.txt
@@ -1008,7 +1008,9 @@ ${CMake_BINARY_DIR}/bin/cmake -DDIR=dev -P 
${CMake_SOURCE_DIR}/Utilities/Release
 if(DPKG_EXECUTABLE)
   unset(CPackRun_CPackDEBConfiguration_ALL_CONFIGS)
   set(DEB_TEST_NAMES CPackComponentsDEB)
-  set(DEB_CONFIGURATIONS_TO_TEST components-lintian-dpkgdeb-checks)
+  set(DEB_CONFIGURATIONS_TO_TEST components-lintian-dpkgdeb-checks
+ components-description1
+ components-description2)
   set(CPackGen DEB)
   set(CPackRun_CPackGen -DCPackGen=${CPackGen})
 
diff --git 
a/Tests/CPackComponentsDEB/MyLibCPackConfig-components-description1.cmake.in 
b/Tests/CPackComponentsDEB/MyLibCPackConfig-components-description1.cmake.in
new file mode 100644
index 000..857e19d
--- /dev/null
+++ b/Tests/CPackComponentsDEB/MyLibCPackConfig-components-description1.cmake.in
@@ -0,0 +1,25 @@
+#
+# Activate component packaging
+#
+
+if(CPACK_GENERATOR MATCHES DEB)
+   set(CPACK_DEB_COMPONENT_INSTALL ON)
+endif()
+
+#
+# Choose grouping way
+#
+#set(CPACK_COMPONENTS_ALL_GROUPS_IN_ONE_PACKAGE)
+#set(CPACK_COMPONENTS_GROUPING)
+set(CPACK_COMPONENTS_IGNORE_GROUPS 1)
+#set(CPACK_COMPONENTS_ALL_IN_ONE_PACKAGE 1

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

[Raffi Enficiaud]

Le 28/04/15 12:23, Domen Vrankar a écrit :

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




Hi,

I did not get exactly what you wanted at the end for the component based 
descriptions, so I left the functionality as is.


So for now, I am addressing the issue CPackDEB: support for description 
per component.


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


I reworked the tests in the same spirit as you did for merging the 
previous patch to master. I will then rebase my other branches on the 
changes you might make. For that purpose, please send me a revision on 
which I can rebase my current work.


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


Best,
Raffi

--

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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

[Raffi Enficiaud]

Le 28/04/15 12:23, Domen Vrankar a écrit :

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



Hi,

I'll resubmit the patches then.

Best,
Raffi


--

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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] Unittests with reconfiguration

[Raffi Enficiaud]

Hi,

I would like to know if it is possible to have a unit test with two runs 
of cmake, simulating a user change of the cache in between.


The workflow would be the following:
- run cmake with default options, cache entries automatically populated
- change some cache value
- run cmake again and check the output and cache output

I am right now looking at RunCMake but I do not think this scheme is 
suitable for that.


Would anyone point me to some test already performing that?

Many thanks,
Raffi

--

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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] Unittests with reconfiguration

[Raffi Enficiaud]

Le 27/04/15 15:22, Brad King a écrit :

On 04/27/2015 07:16 AM, David Cole wrote:

https://github.com/Kitware/CMake/blob/master/Tests/CMakeTestMultipleConfigures/RunCMake.cmake

On Mon, Apr 27, 2015 at 4:13 AM, Raffi Enficiaud wrote:

I would like to know if it is possible to have a unit test with two runs of
cmake, simulating a user change of the cache in between.

I am right now looking at RunCMake but I do not think this scheme is
suitable for that.


We're trying to make RunCMake able to handle all tests that involve
checking the output and generation results.  Its default behavior
is to use a separate build tree for every case and wipe it out
to start fresh each time.  There are options to change this.  Some
tests do what you need already.  For example, look at

  Tests/RunCMake/configure_file/RunCMakeTest.cmake

for use of RunCMake_TEST_BINARY_DIR and RunCMake_TEST_NO_CLEAN.
The pattern followed there has been repeated several times in
other tests, so it may be worth trying to refactor it out into
some kind of helper.

-Brad



Hi,
Thanks both of you for your replies. It looks like the 
configure_file/RunCMakeTest.cmake is exactly what I need!


Best,
Raffi


--

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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

[Raffi Enficiaud]

Le 22/04/15 23:46, Domen Vrankar a écrit :

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


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?

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


Thanks,

Best,
Raffi

--

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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

[Raffi Enficiaud]

Le 22/04/15 08:01, Domen Vrankar a écrit :

2015-04-21 23:38 GMT+02:00 Raffi Enficiaud raffi.enfici...@mines-paris.org:

Le 21/04/15 23:01, Domen Vrankar a écrit :




There are a few other things to change though.
Take a look at CPackRPM man page:
http://www.cmake.org/cmake/help/v3.2/module/CPackRPM.html?highlight=cpack%20rpm

There is an explanation at the top that component variables override
non component variables and then each non component and component
variable is explained at the same time - without this the man page
will get even longer as it already is without a good reason. Please
change the way you wrote the documentation for your component
variables.

Also put the text:
# The value of `CPACK_DEBIAN_COMP_PACKAGE_DEPENDS` can be set to an
empty string
#  to enable the automatic discovery of dependencies without inheriting from
#  the default value of :variable:`CPACK_DEBIAN_PACKAGE_DEPENDS`.

inside a Note so that it will be more visible.

Thanks,
Domen



Hi,

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.

There are a couple of things though:
- the variable CPACK_PACKAGE_CONTACT does not exist anywhere in the code
- 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.


Best,
Raffi
From 870d8e9e1041daf46a89f061eacd36690286687f Mon Sep 17 00:00:00 2001
From: Raffi Enficiaud raffi.enfici...@mines-paris.org
Date: Fri, 24 Apr 2015 17:03:47 +0200
Subject: [PATCH] CPackDeb: reworked documentation

---
 Modules/CPackDeb.cmake | 224 +
 1 file changed, 134 insertions(+), 90 deletions(-)

diff --git a/Modules/CPackDeb.cmake b/Modules/CPackDeb.cmake
index 07cd1bc..869941c 100644
--- a/Modules/CPackDeb.cmake
+++ b/Modules/CPackDeb.cmake
@@ -15,214 +15,258 @@
 # the build system.
 #
 # CPackDeb has specific features which are controlled by the specifics
-# CPACK_DEBIAN_XXX variables.You'll find a detailed usage on the wiki:
-# http://www.cmake.org/Wiki/CMake:CPackPackageGenerators#DEB_.28UNIX_only.29
+# :code:`CPACK_DEBIAN_XXX` variables. 
 #
+# :code:`CPACK_DEBIAN_COMP_` variables may be used in order to have
+# **component** specific values.  Note however that COMP refers
+# to the **grouping name**.  This may be either a component name or a
+# component GROUP name.
+#
+# You'll find a detailed usage on the wiki:
+# http://www.cmake.org/Wiki/CMake:CPackPackageGenerators#DEB_.28UNIX_only.29 .
 # However as a handy reminder here comes the list of specific variables:
 #
+#
 # .. variable:: CPACK_DEBIAN_PACKAGE_NAME
 #
+#  The debian package summary
+#
 #  * Mandatory : YES
-#  * Default   : CPACK_PACKAGE_NAME (lower case)
+#  * Default   : :variable:`CPACK_PACKAGE_NAME` (lower case)
 #
-#  The debian package summary
 #
 # .. variable:: CPACK_DEBIAN_PACKAGE_VERSION
 #
+#  The debian package version
+#
 #  * Mandatory : YES
-#  * Default   : CPACK_PACKAGE_VERSION
+#  * Default   : :variable:`CPACK_PACKAGE_VERSION`
 #
-#  The debian package version
 #
 # .. variable:: CPACK_DEBIAN_PACKAGE_ARCHITECTURE
 #
+#  The debian package architecture
+#
 #  * Mandatory : YES
-#  * Default   : Output of dpkg --print-architecture (or i386 if dpkg is not 
found)
+#  * Default   : Output of :code:`dpkg --print-architecture` (or :code:`i386`
+#if :code:`dpkg` is not found)
 #
-#  The debian package architecture
 #
 # .. variable:: CPACK_DEBIAN_PACKAGE_DEPENDS
+#   CPACK_DEBIAN_COMP_PACKAGE_DEPENDS
+#
+#  May be used to set deb dependencies.
 #
 #  * Mandatory : NO
-#  * Default   : -
+#  * Default   :
 #
-#  May be used to set deb dependencies.
+#- An empty string for non-component based installations
+#- :variable:`CPACK_DEBIAN_PACKAGE_DEPENDS` for component-based
+#  installations.
 #
-# .. variable:: CPACK_DEBIAN_COMP_PACKAGE_DEPENDS
+#  .. note::
 #
-#  * Mandatory : NO
-#  * Default   : :variable:`CPACK_DEBIAN_PACKAGE_DEPENDS`
+#If :variable:`CPACK_DEBIAN_PACKAGE_SHLIBDEPS` or
+#more specifically :variable:`CPACK_DEBIAN_COMP_PACKAGE_SHLIBDEPS` is
+#set for this component, the discovered dependencies will be appended
+#to :variable:`CPACK_DEBIAN_COMP_PACKAGE_DEPENDS` intead of
+#:variable:`CPACK_DEBIAN_PACKAGE_DEPENDS`. If
+#:variable:`CPACK_DEBIAN_COMP_PACKAGE_DEPENDS` is an empty string, only

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

[Raffi Enficiaud]

Le 22/04/15 08:01, Domen Vrankar a écrit :

2015-04-21 23:38 GMT+02:00 Raffi Enficiaud raffi.enfici...@mines-paris.org:

Le 21/04/15 23:01, Domen Vrankar a écrit :


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.



Ok. I might help in the future if you point me on a specific line and
explain me the mistake.


Almost every line in your cmake scripts that uses set, if, string or
other commands (see the explanation below).
I wouldn't be bothering you with that and fix it myself if the test
wouldn't be failing and some other changes needed to be done.



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.



It might help if you send me the test log file of the run.


I'll send you the data in the afternoon.


On the other
hand, I do not understand why it would be an error if ${dpkg_depends} is
an empty string. (I should still be able to find from an empty string,
shouldn't I?)


If you take a look at the code it searches for lib inside
${dpkg_depends} and then the next line checks if it found the content
and prints out an error instead (so the test fails) - that is the
expected way of your test failing.

On the other hand since the value of ${dpkg_depends} is an empty
string that value doesn't contain a value... So without quotes it is
the same as if that variable would not even exist in the above string
command (there is no empty string - the variable gets substituted by
the content of that variable so it's the same as writing nothing) -
and test failing like that is probably not what you intended.

The other reason is that set(some_var some_value other_value) creates
a list and set(some_var some_value) creates a string (list with one
value) and set(var foo bar) set(other_var ${var}) creates an array
from string... Also using set(some_var) is cryptic - it's hard to know
if you meant unset(some_var) or set(some_var )...

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


Hi,

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)


If I understand correctly this should evaluate to false in an if() and 
we should be able to make the distinction with an empty string. On the 
other hand, we can add a variable that may return ok, notfound or 
error.



What are the best practices there?

Best,
Raffi


--

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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

[Raffi Enficiaud]

Le 22/04/15 23:46, Domen Vrankar a écrit :

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


Thanks! I will have a deeper look at it, but right now I can see that 
there is no dependency line in the corresponding debian package. So it 
looks like the shlibdeps did not work for that component.


Should I rebased on a2d36e3?

Best,
Raffi



--

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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

[Raffi Enficiaud]

Le 22/04/15 08:01, Domen Vrankar a écrit :

2015-04-21 23:38 GMT+02:00 Raffi Enficiaud raffi.enfici...@mines-paris.org:

Le 21/04/15 23:01, Domen Vrankar a écrit :


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.



Ok. I might help in the future if you point me on a specific line and
explain me the mistake.


Almost every line in your cmake scripts that uses set, if, string or
other commands (see the explanation below).
I wouldn't be bothering you with that and fix it myself if the test
wouldn't be failing and some other changes needed to be done.



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.



It might help if you send me the test log file of the run.


I'll send you the data in the afternoon.


On the other
hand, I do not understand why it would be an error if ${dpkg_depends} is
an empty string. (I should still be able to find from an empty string,
shouldn't I?)


If you take a look at the code it searches for lib inside
${dpkg_depends} and then the next line checks if it found the content
and prints out an error instead (so the test fails) - that is the
expected way of your test failing.

On the other hand since the value of ${dpkg_depends} is an empty
string that value doesn't contain a value... So without quotes it is
the same as if that variable would not even exist in the above string
command (there is no empty string - the variable gets substituted by
the content of that variable so it's the same as writing nothing) -
and test failing like that is probably not what you intended.

The other reason is that set(some_var some_value other_value) creates
a list and set(some_var some_value) creates a string (list with one
value) and set(var foo bar) set(other_var ${var}) creates an array
from string... Also using set(some_var) is cryptic - it's hard to know
if you meant unset(some_var) or set(some_var )...


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.



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

?


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 )

?

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)



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.





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.



I won't be able to install a Debian box any time soon.


OK I'll send you the generated data and do the rest of the
testing/fixing of the test myself.


Please do (refer to my previous message).



There are a few other things to change though

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

[Raffi Enficiaud]

Le 20/04/15 22:23, Domen Vrankar a écrit :

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




Please find attached the first patch that adds the tests to the Debian 
packaging, and performs a simple check on the md5sum file permissions 
(fix also in the patch).


This patch is based on 268e008c1c448fd3652c0cf196437ede85c37880.

This patch is intended to add the test layer to the DEB packages needed 
by the subsequent changes I will make. Please indicate me if there is 
any issue in integrating this patch, as I will base my work on this one.


The others patches will follow on the same format (based on this one).

Best,
Raffi

From eea580aacc6f8b765c5f356d7eb3ca8225b8ea54 Mon Sep 17 00:00:00 2001
From: Raffi Enficiaud raffi.enfici...@mines-paris.org
Date: Tue, 21 Apr 2015 10:23:23 +0200
Subject: [PATCH] New tests for the Debian packaging:

- adding functions for lintian and dpkg-deb checks
- checking the one file per component without groups configuration
- fixing a warning in lintian about the md5sum file permissions
- checking the Maintainer field in the generated packages
---
 Source/CPack/cmCPackDebGenerator.cxx   |   4 +
 Tests/CMakeLists.txt   |  36 
 Tests/CPackComponentsDEB/CMakeLists.txt| 106 ++
 ...tted-components-lintian-dpkgdeb-checks.cmake.in |  15 ++
 ...plitted-components-lintian-dpkgdeb-checks.cmake |  78 
 .../CPackComponentsDEB/RunCPackVerifyResult.cmake  | 217 +
 Tests/CPackComponentsDEB/license.txt   |   3 +
 Tests/CPackComponentsDEB/mylib.cpp |   7 +
 Tests/CPackComponentsDEB/mylib.h   |   1 +
 Tests/CPackComponentsDEB/mylibapp.cpp  |   6 +
 10 files changed, 473 insertions(+)
 create mode 100644 Tests/CPackComponentsDEB/CMakeLists.txt
 create mode 100644 
Tests/CPackComponentsDEB/MyLibCPackConfig-splitted-components-lintian-dpkgdeb-checks.cmake.in
 create mode 100644 
Tests/CPackComponentsDEB/RunCPackVerifyResult-splitted-components-lintian-dpkgdeb-checks.cmake
 create mode 100644 Tests/CPackComponentsDEB/RunCPackVerifyResult.cmake
 create mode 100644 Tests/CPackComponentsDEB/license.txt
 create mode 100644 Tests/CPackComponentsDEB/mylib.cpp
 create mode 100644 Tests/CPackComponentsDEB/mylib.h
 create mode 100644 Tests/CPackComponentsDEB/mylibapp.cpp

diff --git a/Source/CPack/cmCPackDebGenerator.cxx 
b/Source/CPack/cmCPackDebGenerator.cxx
index 1c2c001..c6d828e 100644
--- a/Source/CPack/cmCPackDebGenerator.cxx
+++ b/Source/CPack/cmCPackDebGenerator.cxx
@@ -20,6 +20,7 @@
 #include cmsys/Glob.hxx
 
 #include limits.h // USHRT_MAX
+#include sys/stat.h
 
 // NOTE:
 // A debian package .deb is simply an 'ar' archive. The only subtle difference
@@ -523,6 +524,9 @@ int cmCPackDebGenerator::createDeb()
 // each line contains a eol.
 // Do not end the md5sum file with yet another (invalid)
 }
+
+// lintian warning otherwise
+cmSystemTools::SetPermissions(md5filename.c_str(), S_IRUSR | S_IWUSR | 
S_IRGRP | S_IROTH);
 
 cmd = this-GetOption(GEN_CPACK_DEBIAN_FAKEROOT_EXECUTABLE);
 cmd += cmake_tar + tar czf control.tar.gz ./control ./md5sums;
diff --git a/Tests/CMakeLists.txt b/Tests/CMakeLists.txt
index b474d32..8145d91 100644
--- a/Tests/CMakeLists.txt
+++ b/Tests/CMakeLists.txt
@@ -1003,6 +1003,42 @@ ${CMake_BINARY_DIR}/bin/cmake -DDIR=dev -P 
${CMake_SOURCE_DIR}/Utilities/Release
 list(APPEND TEST_BUILD_DIRS 
${CMake_BINARY_DIR}/Tests/CPackComponentsForAll/build${CPackGen}-${CPackComponentWay})
   endforeach()
 endforeach()
+
+# debian specific
+if(DPKG_EXECUTABLE)
+set(CPackRun_CPackDEBConfiguration_ALL_CONFIGS)
+set(DEB_TEST_NAMES CPackComponentsDEB)
+set(DEB_CONFIGURATIONS_TO_TEST 
splitted-components-lintian-dpkgdeb-checks)
+set(CPackGen DEB)
+set(CPackRun_CPackGen -DCPackGen=${CPackGen})
+
+foreach(CPackDEBConfiguration ${DEB_CONFIGURATIONS_TO_TEST})
+set(CPackRun_CPackDEBConfiguration 
-DCPackDEBConfiguration=${CPackDEBConfiguration})
+add_test(${DEB_TEST_NAMES}-${CPackDEBConfiguration}
+ ${CMAKE_CTEST_COMMAND} -C \${CTEST_CONFIGURATION_TYPE}
+ --build-and-test
+${CMake_SOURCE_DIR}/Tests/${DEB_TEST_NAMES}
+
${CMake_BINARY_DIR}/Tests/${DEB_TEST_NAMES}/build${CPackGen}-${CPackDEBConfiguration}
+${build_generator_args}
+ --build-project CPackComponentsDEB
+ --build-options ${build_options}
+  -DCPACK_GENERATOR:STRING=${CPackGen}
+  -DCPACK_BINARY_${CPackGen}:BOOL=ON
+  ${CPackRun_CPackDEBConfiguration}
+  ${CPackRun_CPackDEBConfiguration_ALL_CONFIGS

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

[Raffi Enficiaud]

Le 21/04/15 16:41, Raffi Enficiaud a écrit :

Le 21/04/15 14:36, Raffi Enficiaud a écrit :

Le 18/04/15 09:58, Raffi Enficiaud a écrit :

Le 18/04/15 09:34, Domen Vrankar a écrit :


The way you implemented it you are not covering the case:
1) CPACK_DEBIAN_PACKAGE_DESCRIPTION no set
2) CPACK_DEBIAN_PACKAGE_DESCRIPTION is set with component description
3) next component doesn't set per component description so
CPACK_DEBIAN_PACKAGE_DESCRIPTION is not reset and description of the
previous component is used

Or if 1) would be set and 3 not set you would loose the initial
description


Ok. I worked essentially on having the tests kind of functional. I will
add the cases you mentioned in new tests.



Please find attached the patch that allows a description per component.
I believe I created a test covering the issue you mentioned above.


Raffi





Please find attached the patch that enables the setting of the
dependency discovery per-component. This patch is based on the previous
one (description per component), but is rather independent. The next
patch, dependency per component, will depend on the changes made by the
attached patch.

Best,
Raffi




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


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.


Any feedback more than welcome.

Best,
Raffi
From d43784c761d4e2d23fb8242eb194c88baa808da5 Mon Sep 17 00:00:00 2001
From: Raffi Enficiaud raffi.enfici...@tuebingen.mpg.de
Date: Tue, 21 Apr 2015 17:15:00 +0200
Subject: [PATCH] CPackDEB: Enabling the settings of the dependencies per
 component.

---
 Modules/CPackDeb.cmake | 49 ++--
 Tests/CMakeLists.txt   |  2 +
 ...PackConfig-splitted-components-depend1.cmake.in | 20 +
 ...PackConfig-splitted-components-depend2.cmake.in | 29 +++
 ...kVerifyResult-splitted-components-depend1.cmake | 83 
 ...kVerifyResult-splitted-components-depend2.cmake | 91 ++
 6 files changed, 268 insertions(+), 6 deletions(-)
 create mode 100644 
Tests/CPackComponentsDEB/MyLibCPackConfig-splitted-components-depend1.cmake.in
 create mode 100644 
Tests/CPackComponentsDEB/MyLibCPackConfig-splitted-components-depend2.cmake.in
 create mode 100644 
Tests/CPackComponentsDEB/RunCPackVerifyResult-splitted-components-depend1.cmake
 create mode 100644 
Tests/CPackComponentsDEB/RunCPackVerifyResult-splitted-components-depend2.cmake

diff --git a/Modules/CPackDeb.cmake b/Modules/CPackDeb.cmake
index acdb82c..07cd1bc 100644
--- a/Modules/CPackDeb.cmake
+++ b/Modules/CPackDeb.cmake
@@ -48,6 +48,20 @@
 #
 #  May be used to set deb dependencies.
 #
+# .. variable:: CPACK_DEBIAN_COMP_PACKAGE_DEPENDS
+#
+#  * Mandatory : NO
+#  * Default   : :variable:`CPACK_DEBIAN_PACKAGE_DEPENDS`
+#
+#  Indicates the debian package dependencies for a specific component 'COMP'.
+#  This value has priority over :variable:`CPACK_DEBIAN_PACKAGE_DEPENDS`. If
+#  :variable:`CPACK_DEBIAN_PACKAGE_SHLIBDEPS` is set, then the discovered
+#  dependencies will be appended to `CPACK_DEBIAN_COMP_PACKAGE_DEPENDS` if 
set
+#  (intead of `CPACK_DEBIAN_PACKAGE_DEPENDS`).
+#  The value of `CPACK_DEBIAN_COMP_PACKAGE_DEPENDS` can be set to an empty 
string
+#  to enable the automatic discovery of dependencies without inheriting from
+#  the default value of :variable:`CPACK_DEBIAN_PACKAGE_DEPENDS`.
+#
 # .. variable:: CPACK_DEBIAN_PACKAGE_MAINTAINER
 #
 #  * Mandatory : YES
@@ -343,12 +357,8 @@ function(cpack_deb_prepare_package_vars)
   # Might not be safe if package actual contain file or directory named 
debian
   file(REMOVE_RECURSE ${CPACK_TEMPORARY_DIRECTORY}/debian)
 
-  # Append user depend if set
-  if (CPACK_DEBIAN_PACKAGE_DEPENDS)
-set (CPACK_DEBIAN_PACKAGE_DEPENDS 
${CPACK_DEBIAN_PACKAGE_AUTO_DEPENDS}, ${CPACK_DEBIAN_PACKAGE_DEPENDS})
-  else ()
-set (CPACK_DEBIAN_PACKAGE_DEPENDS 
${CPACK_DEBIAN_PACKAGE_AUTO_DEPENDS})
-  endif ()
+  # this is too early to populate the CPACK_DEBIAN_PACKAGE_DEPENDS, as the 
way to do it
+  # is configuration dependant (component, etc)
 
 else ()
   if(CPACK_DEBIAN_PACKAGE_DEBUG)
@@ -402,6 +412,33 @@ function(cpack_deb_prepare_package_vars)
   # Depends:
   # You should set: DEBIAN_PACKAGE_DEPENDS
   # TODO: automate 'objdump -p | grep NEEDED'
+  
+  # if per-component dependency, overrides the global 
CPACK_DEBIAN_PACKAGE_DEPENDS
+  # automatic dependency discovery will be performed afterwards.
+  if(CPACK_DEB_PACKAGE_COMPONENT)
+string(TOUPPER ${CPACK_DEB_PACKAGE_COMPONENT} _local_component_name)
+set(_component_depends_var 
CPACK_DEBIAN_${_local_component_name}_PACKAGE_DEPENDS)
+
+# if set, overrides the global dependency
+if(DEFINED ${_component_depends_var})
+  set(CPACK_DEBIAN_PACKAGE_DEPENDS

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

[Raffi Enficiaud]

Le 21/04/15 14:36, Raffi Enficiaud a écrit :

Le 18/04/15 09:58, Raffi Enficiaud a écrit :

Le 18/04/15 09:34, Domen Vrankar a écrit :


The way you implemented it you are not covering the case:
1) CPACK_DEBIAN_PACKAGE_DESCRIPTION no set
2) CPACK_DEBIAN_PACKAGE_DESCRIPTION is set with component description
3) next component doesn't set per component description so
CPACK_DEBIAN_PACKAGE_DESCRIPTION is not reset and description of the
previous component is used

Or if 1) would be set and 3 not set you would loose the initial
description


Ok. I worked essentially on having the tests kind of functional. I will
add the cases you mentioned in new tests.



Please find attached the patch that allows a description per component.
I believe I created a test covering the issue you mentioned above.


Raffi






Please find attached the patch that enables the setting of the 
dependency discovery per-component. This patch is based on the previous 
one (description per component), but is rather independent. The next 
patch, dependency per component, will depend on the changes made by the 
attached patch.


Best,
Raffi

From 618ce62aa9c9a53b1091452031c84d01c19ed45c Mon Sep 17 00:00:00 2001
From: Raffi Enficiaud raffi.enfici...@tuebingen.mpg.de
Date: Tue, 21 Apr 2015 16:37:00 +0200
Subject: [PATCH] CPackDEB: Enabling the dependency auto-discovery per
 component

---
 Modules/CPackDeb.cmake | 26 
 Tests/CMakeLists.txt   |  1 +
 ...kConfig-splitted-components-shlibdeps1.cmake.in | 24 
 ...rifyResult-splitted-components-shlibdeps1.cmake | 70 ++
 4 files changed, 121 insertions(+)
 create mode 100644 
Tests/CPackComponentsDEB/MyLibCPackConfig-splitted-components-shlibdeps1.cmake.in
 create mode 100644 
Tests/CPackComponentsDEB/RunCPackVerifyResult-splitted-components-shlibdeps1.cmake

diff --git a/Modules/CPackDeb.cmake b/Modules/CPackDeb.cmake
index 1a1270e..acdb82c 100644
--- a/Modules/CPackDeb.cmake
+++ b/Modules/CPackDeb.cmake
@@ -114,6 +114,15 @@
 #  may fail to find your own shared libs.
 #  See http://www.cmake.org/Wiki/CMake_RPATH_handling.
 #
+# .. variable:: CPACK_DEBIAN_comp_PACKAGE_SHLIBDEPS
+#
+#  * Mandatory : NO
+#  * Default   : CPACK_DEBIAN_PACKAGE_SHLIBDEPS
+#
+#  Same as `CPACK_DEBIAN_PACKAGE_SHLIBDEPS` but for one specific component.
+#  If set (either to ON or OFF) it overrides the default given by
+#  `CPACK_DEBIAN_PACKAGE_SHLIBDEPS`.
+#
 # .. variable:: CPACK_DEBIAN_PACKAGE_DEBUG
 #
 #  * Mandatory : NO
@@ -245,6 +254,23 @@ function(cpack_deb_prepare_package_vars)
 set(CPACK_DEBIAN_FAKEROOT_EXECUTABLE ${FAKEROOT_EXECUTABLE})
   endif()
 
+  
+  # per component automatic discover: some of the component might not have
+  # binaries. 
+  if(CPACK_DEB_PACKAGE_COMPONENT)
+string(TOUPPER ${CPACK_DEB_PACKAGE_COMPONENT} _local_component_name)
+set(_component_shlibdeps_var 
CPACK_DEBIAN_${_local_component_name}_PACKAGE_SHLIBDEPS)
+
+# if set, overrides the global configuration
+if(DEFINED ${_component_shlibdeps_var})
+  set(CPACK_DEBIAN_PACKAGE_SHLIBDEPS ${${_component_shlibdeps_var}})
+  if(CPACK_DEBIAN_PACKAGE_DEBUG)
+message(CPackDeb Debug: component '${CPACK_DEB_PACKAGE_COMPONENT}' 
dpkg-shlibdeps set to ${CPACK_DEBIAN_PACKAGE_SHLIBDEPS})
+  endif()
+endif()
+  endif()
+
+
   if(CPACK_DEBIAN_PACKAGE_SHLIBDEPS)
 # dpkg-shlibdeps is a Debian utility for generating dependency list
 find_program(SHLIBDEPS_EXECUTABLE dpkg-shlibdeps)
diff --git a/Tests/CMakeLists.txt b/Tests/CMakeLists.txt
index 2adb7e7..35683b5 100644
--- a/Tests/CMakeLists.txt
+++ b/Tests/CMakeLists.txt
@@ -1011,6 +1011,7 @@ ${CMake_BINARY_DIR}/bin/cmake -DDIR=dev -P 
${CMake_SOURCE_DIR}/Utilities/Release
 set(DEB_CONFIGURATIONS_TO_TEST 
splitted-components-lintian-dpkgdeb-checks
splitted-components-description1
splitted-components-description2
+   splitted-components-shlibdeps1
)
 set(CPackGen DEB)
 set(CPackRun_CPackGen -DCPackGen=${CPackGen})
diff --git 
a/Tests/CPackComponentsDEB/MyLibCPackConfig-splitted-components-shlibdeps1.cmake.in
 
b/Tests/CPackComponentsDEB/MyLibCPackConfig-splitted-components-shlibdeps1.cmake.in
new file mode 100644
index 000..cfe6df5
--- /dev/null
+++ 
b/Tests/CPackComponentsDEB/MyLibCPackConfig-splitted-components-shlibdeps1.cmake.in
@@ -0,0 +1,24 @@
+#
+# Activate component packaging
+#
+
+if(CPACK_GENERATOR MATCHES DEB)
+   set(CPACK_DEB_COMPONENT_INSTALL ON)
+endif()
+
+#
+# Choose grouping way
+#
+#set(CPACK_COMPONENTS_ALL_GROUPS_IN_ONE_PACKAGE)
+#set(CPACK_COMPONENTS_GROUPING)
+set(CPACK_COMPONENTS_IGNORE_GROUPS 1)
+#set(CPACK_COMPONENTS_ALL_IN_ONE_PACKAGE 1)
+
+# we set shlibdeps to on
+set(CPACK_DEBIAN_PACKAGE_SHLIBDEPS ON)
+# except for the component headers that do not contain

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

[Raffi Enficiaud]

Le 18/04/15 09:58, Raffi Enficiaud a écrit :

Le 18/04/15 09:34, Domen Vrankar a écrit :


The way you implemented it you are not covering the case:
1) CPACK_DEBIAN_PACKAGE_DESCRIPTION no set
2) CPACK_DEBIAN_PACKAGE_DESCRIPTION is set with component description
3) next component doesn't set per component description so
CPACK_DEBIAN_PACKAGE_DESCRIPTION is not reset and description of the
previous component is used

Or if 1) would be set and 3 not set you would loose the initial
description


Ok. I worked essentially on having the tests kind of functional. I will
add the cases you mentioned in new tests.



Please find attached the patch that allows a description per component. 
I believe I created a test covering the issue you mentioned above.



Raffi

From 204f02edc5ac330053becb45fbec3b2ec5f2f535 Mon Sep 17 00:00:00 2001
From: Raffi Enficiaud raffi.enfici...@tuebingen.mpg.de
Date: Tue, 21 Apr 2015 14:30:43 +0200
Subject: [PATCH] Enabling the description per components

---
 Modules/CPackDeb.cmake | 37 --
 Tests/CMakeLists.txt   |  5 +-
 ...onfig-splitted-components-description1.cmake.in | 25 +++
 ...onfig-splitted-components-description2.cmake.in | 29 
 ...fyResult-splitted-components-description1.cmake | 83 ++
 ...fyResult-splitted-components-description2.cmake | 83 ++
 6 files changed, 257 insertions(+), 5 deletions(-)
 create mode 100644 
Tests/CPackComponentsDEB/MyLibCPackConfig-splitted-components-description1.cmake.in
 create mode 100644 
Tests/CPackComponentsDEB/MyLibCPackConfig-splitted-components-description2.cmake.in
 create mode 100644 
Tests/CPackComponentsDEB/RunCPackVerifyResult-splitted-components-description1.cmake
 create mode 100644 
Tests/CPackComponentsDEB/RunCPackVerifyResult-splitted-components-description2.cmake

diff --git a/Modules/CPackDeb.cmake b/Modules/CPackDeb.cmake
index f248a67..1a1270e 100644
--- a/Modules/CPackDeb.cmake
+++ b/Modules/CPackDeb.cmake
@@ -62,6 +62,16 @@
 #
 #  The debian package description
 #
+# .. variable:: CPACK_COMPONENT_COMP_DESCRIPTION
+#
+#  * Mandatory : NO
+#  * Default   : CPACK_DEBIAN_PACKAGE_DESCRIPTION
+#
+#  The debian package description for a specific component 'COMP'.
+#  This description has priority over the other descriptions given by
+#  :variable:`CPACK_DEBIAN_PACKAGE_DESCRIPTION` and
+#  :variable:`CPACK_PACKAGE_DESCRIPTION_SUMMARY`.
+#
 # .. variable:: CPACK_DEBIAN_PACKAGE_SECTION
 #
 #  * Mandatory : YES
@@ -379,11 +389,30 @@ function(cpack_deb_prepare_package_vars)
   endif()
 
   # Description: (mandatory)
-  if(NOT CPACK_DEBIAN_PACKAGE_DESCRIPTION)
-if(NOT CPACK_PACKAGE_DESCRIPTION_SUMMARY)
-  message(FATAL_ERROR CPackDeb: Debian package requires a summary for a 
package, set CPACK_PACKAGE_DESCRIPTION_SUMMARY or 
CPACK_DEBIAN_PACKAGE_DESCRIPTION)
+  if(NOT CPACK_DEB_PACKAGE_COMPONENT)
+if(NOT CPACK_DEBIAN_PACKAGE_DESCRIPTION)
+  if(NOT CPACK_PACKAGE_DESCRIPTION_SUMMARY)
+message(FATAL_ERROR CPackDeb: Debian package requires a summary for a 
package, set CPACK_PACKAGE_DESCRIPTION_SUMMARY or 
CPACK_DEBIAN_PACKAGE_DESCRIPTION)
+  endif()
+  set(CPACK_DEBIAN_PACKAGE_DESCRIPTION 
${CPACK_PACKAGE_DESCRIPTION_SUMMARY})
+endif()
+  else()
+string(TOUPPER ${CPACK_DEB_PACKAGE_COMPONENT} _local_component_name)
+set(component_description_var 
CPACK_COMPONENT_${_local_component_name}_DESCRIPTION)
+
+# component description overrides package description
+if(${component_description_var})
+  set(CPACK_DEBIAN_PACKAGE_DESCRIPTION ${${component_description_var}})
+elseif(CPACK_DEBIAN_PACKAGE_DESCRIPTION)
+  # do nothing
+else()
+  if(NOT CPACK_PACKAGE_DESCRIPTION_SUMMARY)
+message(FATAL_ERROR CPackDeb: Debian package requires a summary for a 
package, set CPACK_PACKAGE_DESCRIPTION_SUMMARY or 
CPACK_DEBIAN_PACKAGE_DESCRIPTION
+ or ${component_description_var})
+  endif()
+  set(CPACK_DEBIAN_PACKAGE_DESCRIPTION 
${CPACK_PACKAGE_DESCRIPTION_SUMMARY})
 endif()
-set(CPACK_DEBIAN_PACKAGE_DESCRIPTION ${CPACK_PACKAGE_DESCRIPTION_SUMMARY})
+  
   endif()
 
   # Section: (recommended)
diff --git a/Tests/CMakeLists.txt b/Tests/CMakeLists.txt
index 8145d91..2adb7e7 100644
--- a/Tests/CMakeLists.txt
+++ b/Tests/CMakeLists.txt
@@ -1008,7 +1008,10 @@ ${CMake_BINARY_DIR}/bin/cmake -DDIR=dev -P 
${CMake_SOURCE_DIR}/Utilities/Release
 if(DPKG_EXECUTABLE)
 set(CPackRun_CPackDEBConfiguration_ALL_CONFIGS)
 set(DEB_TEST_NAMES CPackComponentsDEB)
-set(DEB_CONFIGURATIONS_TO_TEST 
splitted-components-lintian-dpkgdeb-checks)
+set(DEB_CONFIGURATIONS_TO_TEST 
splitted-components-lintian-dpkgdeb-checks
+   splitted-components-description1
+   splitted-components-description2
+   )
 set(CPackGen

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

[Raffi Enficiaud]

Le 21/04/15 23:01, Domen Vrankar a écrit :

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.


Ok. I might help in the future if you point me on a specific line and 
explain me the mistake.




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.


It might help if you send me the test log file of the run. On the other 
hand, I do not understand why it would be an error if ${dpkg_depends} 
is an empty string. (I should still be able to find from an empty 
string, shouldn't I?)



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.


I won't be able to install a Debian box any time soon. The test tests 
the following setup:
- automatic dependency discovery on by default 
(CPACK_DEBIAN_PACKAGE_SHLIBDEPS)

- global/default dependency set (CPACK_DEBIAN_PACKAGE_DEPENDS)
In this case, I do not want the component APPLICATION to inherit from 
the general dependency, but rather let the shlibdeps tool do the work.

This is why I do the following:
set(CPACK_DEBIAN_APPLICATIONS_PACKAGE_DEPENDS )

In this case, the component dependency is set, which prevents inheriting 
from CPACK_DEBIAN_PACKAGE_DEPENDS, and only the result of shlibdeps go 
to the package.


Best,
Raffi Enficiaud


--

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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

[Raffi Enficiaud]

Le 18/04/15 09:34, Domen Vrankar a écrit :

I added the following functionalities:
- set the permissions of the md5sum to RW-R--R--, because lintian
complains
- added an option to set the shlibdeps per component
- added an option to set the dependencies per component
- added an option to set the description per component


The way you implemented it you are not covering the case:
1) CPACK_DEBIAN_PACKAGE_DESCRIPTION no set
2) CPACK_DEBIAN_PACKAGE_DESCRIPTION is set with component description
3) next component doesn't set per component description so
CPACK_DEBIAN_PACKAGE_DESCRIPTION is not reset and description of the
previous component is used

Or if 1) would be set and 3 not set you would loose the initial description

There is a simple solution for variables overflowing between
components - just wrap the entire code into a function (see CPackRPM
cpack_rpm_generate_package() function) - since such a change messes up
the entire diff (indentations) this should be an entirely separate
patch. This solution would also simplify the shlibdeps patch since you
would no longer need to set CPACK_DEBIAN_PACKAGE_AUTO_DEPENDS to empty
value and unset it when you no longer need it.


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.


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.

Best,
Raffi

--

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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

[Raffi Enficiaud]

Le 20/04/15 19:19, Domen Vrankar a écrit :

Hi,
[...]
- 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.


no worries!




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.


Ok



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.


Ok



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.


For instance, if I have to implement the inter-component dependency, I 
though a possible implementation would be


- loop through all the components and get back eg. the component 
debianized name, without generating the package (kind of dry-run)

- put all those names into a map that is available to the generator
- loop through all the components, with this map available, and generate 
the component package.


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


I do not know that much the interface between the C++ and .cmake (for 
example, I do not know if this is possible to get all _cpack_deb_local_* 
variables, or call only one function of the .cmake instead).




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.

Best,
Raffi

Raffi

--

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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

[Raffi Enficiaud]

Le 18/04/15 09:34, Domen Vrankar a écrit :

I added the following functionalities:
- set the permissions of the md5sum to RW-R--R--, because lintian
complains
- added an option to set the shlibdeps per component
- added an option to set the dependencies per component
- added an option to set the description per component


The way you implemented it you are not covering the case:
1) CPACK_DEBIAN_PACKAGE_DESCRIPTION no set
2) CPACK_DEBIAN_PACKAGE_DESCRIPTION is set with component description
3) next component doesn't set per component description so
CPACK_DEBIAN_PACKAGE_DESCRIPTION is not reset and description of the
previous component is used

Or if 1) would be set and 3 not set you would loose the initial description


Ok. I worked essentially on having the tests kind of functional. I will 
add the cases you mentioned in new tests.




There is a simple solution for variables overflowing between
components - just wrap the entire code into a function (see CPackRPM
cpack_rpm_generate_package() function) - since such a change messes up
the entire diff (indentations) this should be an entirely separate
patch. This solution would also simplify the shlibdeps patch since you
would no longer need to set CPACK_DEBIAN_PACKAGE_AUTO_DEPENDS to empty
value and unset it when you no longer need it.


Ok, I will try.




- enforcing the lower case policy of Debian for package names (in the
file, due to the comment # debian policy enforce lower case for package
name)


Since you are fixing multiple non related issues at the same time
please split the patch into separate commits so that it can easier be
seen which change fixes which issue.


Ok.



You are also leaving trailing whitespaces in patches - those should be removed.


I will clean the code, yes.




On the other hand, I started writing tests based on the one existing for
the CPackComponentsAll, but specific to debian packages:
- added a function for running lintian and checking for some errors. The
md5sum permission change is now covered by that
- added a function for running dpkg-deb and extracting a particular
field of the package metadata. No change I made are currently covered by
this function, this is what I will do next.
- Having one specific check file per configuration, sharing a common
.cmake providing the check functions (linitian and dpkg-deb). This would
prevent the cluttering of the checks that we can observe in the
CPackComponentsAll final test.


I already wrote to the mailing list regarding changing where and how
CPack test should be written but it will take me a few days to
implement... Since you are already splitting tests into separate
scripts it will be easy to move them later on.


I hope so. The added value in the tests I wrote so far is the 
possibility to inspect the generated packages with the Debian tools, and 
some refactoring (I found difficult to have several config files and one 
check file for all generators).






Sorry that was too quick. Here are the open questions:
- if a component depends on another component, should we add the dependency
automatically?


I'd say no by default so that we don't break back compatibility
unnecessarily but the feature should be enabled through a variable
(e.g. CPACK_DEBIAN_COMPONENTS_AUTODEPEND ON - and also per component
version).


I agree with that.




- What about the version of this dependency?

Let's say I have components A and B, and B depends on A. I am at version X.
Dependencies of A are d11, d12, d1N,
Dependencies of B are d21, d22, d2P

Should the generation of the package B include d2(P+1)= A (= versionX) ?


For the first patch I would omit versions of dependencies. Later this
can be added with additional possibility to change = to = for adding
minimal required version (e.g.
CPACK_DEBIAN_COMPONENT_name_DEPENDS_dependency some_version) with
the possibility to enable/disable version addition.


Good.

Raffi.


--

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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

[Raffi Enficiaud]

Le 16/04/15 22:31, Brad King a écrit :

On 04/16/2015 04:19 PM, Domen Vrankar wrote:

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


Thanks.  The fixup!  mark is useful only during incremental
development of an open topic.  Once a commit is in 'master'
then it should be explicitly referenced by a later fixup commit
with a normal commit message.  I've revised the commit as:

  CPack: Fix single component packaging
  http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ed0b0630

I also rebased it back on the original commit and renamed the
topic to match.  This makes it look like one topic that was
merged to master in the middle.

-Brad



Ok, here is a patch that shows you the advance. This is not yet a 
candidate for merging to anything, but rather a support for some 
discussions.

It is based on ed0b063 for this particular topic.

I added the following functionalities:
- set the permissions of the md5sum to RW-R--R--, because lintian complains
- added an option to set the shlibdeps per component
- added an option to set the dependencies per component
- added an option to set the description per component
- enforcing the lower case policy of Debian for package names (in the 
file, due to the comment # debian policy enforce lower case for package 
name)


On the other hand, I started writing tests based on the one existing for 
the CPackComponentsAll, but specific to debian packages:
- added a function for running lintian and checking for some errors. The 
md5sum permission change is now covered by that
- added a function for running dpkg-deb and extracting a particular 
field of the package metadata. No change I made are currently covered by 
this function, this is what I will do next.
- Having one specific check file per configuration, sharing a common 
.cmake providing the check functions (linitian and dpkg-deb). This would 
prevent the cluttering of the checks that we can observe in the 
CPackComponentsAll final test.



Of course, your comments are more than welcome.

Best,
Raffi

From 2681e05c844eee5b77568895b5b1329f1377b05b Mon Sep 17 00:00:00 2001
From: Raffi Enficiaud raffi.enfici...@mines-paris.org
Date: Fri, 17 Apr 2015 15:49:33 +0200
Subject: [PATCH] Debian packaging

- enabling a per component shlibdeps
- enabling a per component dependencies
- enabling a per component description
- fixing the file permissions of the auto-generated md5sum
- new tests specific to CPackDeb.cmake with lintian and dpkg-deb
---
 Modules/CPackDeb.cmake |  89 +++--
 Source/CPack/cmCPackDebGenerator.cxx   |   8 +
 Tests/CMakeLists.txt   |  35 
 Tests/CPackComponentsDEB/CMakeLists.txt| 103 ++
 ...Config-one-file-per-component-no-group.cmake.in |  15 ++
 ...ifyResult-one-file-per-component-no-group.cmake |  78 
 .../CPackComponentsDEB/RunCPackVerifyResult.cmake  | 217 +
 Tests/CPackComponentsDEB/license.txt   |   3 +
 Tests/CPackComponentsDEB/mylib.cpp |   7 +
 Tests/CPackComponentsDEB/mylib.h   |   1 +
 Tests/CPackComponentsDEB/mylibapp.cpp  |   6 +
 11 files changed, 550 insertions(+), 12 deletions(-)
 create mode 100644 Tests/CPackComponentsDEB/CMakeLists.txt
 create mode 100644 
Tests/CPackComponentsDEB/MyLibCPackConfig-one-file-per-component-no-group.cmake.in
 create mode 100644 
Tests/CPackComponentsDEB/RunCPackVerifyResult-one-file-per-component-no-group.cmake
 create mode 100644 Tests/CPackComponentsDEB/RunCPackVerifyResult.cmake
 create mode 100644 Tests/CPackComponentsDEB/license.txt
 create mode 100644 Tests/CPackComponentsDEB/mylib.cpp
 create mode 100644 Tests/CPackComponentsDEB/mylib.h
 create mode 100644 Tests/CPackComponentsDEB/mylibapp.cpp

diff --git a/Modules/CPackDeb.cmake b/Modules/CPackDeb.cmake
index 8a4fa49..647b2ae 100644
--- a/Modules/CPackDeb.cmake
+++ b/Modules/CPackDeb.cmake
@@ -104,6 +104,15 @@
 #  may fail to find your own shared libs.
 #  See http://www.cmake.org/Wiki/CMake_RPATH_handling.
 #
+# .. variable:: CPACK_DEBIAN_comp_PACKAGE_SHLIBDEPS
+#
+#  * Mandatory : NO
+#  * Default   : CPACK_DEBIAN_PACKAGE_SHLIBDEPS
+#
+#  Same as `CPACK_DEBIAN_PACKAGE_SHLIBDEPS` but for one specific component.
+#  If set (either to ON or OFF) it overrides the default given by
+#  `CPACK_DEBIAN_PACKAGE_SHLIBDEPS`.
+#
 # .. variable:: CPACK_DEBIAN_PACKAGE_DEBUG
 #
 #  * Mandatory : NO
@@ -229,12 +238,28 @@ if(NOT DEFINED CPACK_DEBIAN_PACKAGE_SHLIBDEPS)
   set(CPACK_DEBIAN_PACKAGE_SHLIBDEPS OFF)
 endif()
 
+set(_cpack_debian_shlibdeps_local ${CPACK_DEBIAN_PACKAGE_SHLIBDEPS})
+
 find_program(FAKEROOT_EXECUTABLE fakeroot)
 if(FAKEROOT_EXECUTABLE)
   set(CPACK_DEBIAN_FAKEROOT_EXECUTABLE ${FAKEROOT_EXECUTABLE})
 endif()
 
-if(CPACK_DEBIAN_PACKAGE_SHLIBDEPS)
+if(CPACK_DEB_PACKAGE_COMPONENT)
+  set(_component_shlibdeps_var 
CPACK_DEBIAN_${CPACK_DEB_PACKAGE_COMPONENT

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

[Raffi Enficiaud]

Le 17/04/15 15:50, Raffi Enficiaud a écrit :

Le 16/04/15 22:31, Brad King a écrit :

On 04/16/2015 04:19 PM, Domen Vrankar wrote:

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


Thanks.  The fixup!  mark is useful only during incremental
development of an open topic.  Once a commit is in 'master'
then it should be explicitly referenced by a later fixup commit
with a normal commit message.  I've revised the commit as:

  CPack: Fix single component packaging
  http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ed0b0630

I also rebased it back on the original commit and renamed the
topic to match.  This makes it look like one topic that was
merged to master in the middle.

-Brad



Ok, here is a patch that shows you the advance. This is not yet a
candidate for merging to anything, but rather a support for some
discussions.
It is based on ed0b063 for this particular topic.

I added the following functionalities:
- set the permissions of the md5sum to RW-R--R--, because lintian complains
- added an option to set the shlibdeps per component
- added an option to set the dependencies per component
- added an option to set the description per component
- enforcing the lower case policy of Debian for package names (in the
file, due to the comment # debian policy enforce lower case for package
name)

On the other hand, I started writing tests based on the one existing for
the CPackComponentsAll, but specific to debian packages:
- added a function for running lintian and checking for some errors. The
md5sum permission change is now covered by that
- added a function for running dpkg-deb and extracting a particular
field of the package metadata. No change I made are currently covered by
this function, this is what I will do next.
- Having one specific check file per configuration, sharing a common
.cmake providing the check functions (linitian and dpkg-deb). This would
prevent the cluttering of the checks that we can observe in the
CPackComponentsAll final test.


Of course, your comments are more than welcome.




Sorry that was too quick. Here are the open questions:
- if a component depends on another component, should we add the 
dependency automatically?

- What about the version of this dependency?

Let's say I have components A and B, and B depends on A. I am at version X.
Dependencies of A are d11, d12, d1N,
Dependencies of B are d21, d22, d2P

Should the generation of the package B include d2(P+1)= A (= versionX) ?

Best,
Raffi


--

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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

[Raffi Enficiaud]

Le 09/03/11 14:29, Mantis Bug Tracker a écrit :


The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=11944
==
Reported By:Martin Konrad
Assigned To:
==
Project:CMake
Issue ID:   11944
Category:   CPack
Reproducibility:always
Severity:   feature
Priority:   normal
Status: new
==
Date Submitted: 2011-03-09 08:29 EST
Last Modified:  2011-03-09 08:29 EST
==
Summary:CPackDeb: Support dependencies between
components/Debian packages
Description:
The patch provided in http://public.kitware.com/Bug/view.php?id=11655 does not
transform the dependencies between CMake components into dependencies between
the resulting Debian packages.
==

Issue History
Date ModifiedUsername   FieldChange
==
2011-03-09 08:29 Martin Konrad  New Issue
==



Hi all,

I was wondering if this issue has been addressed so far. It is also 
related to this thread I think, which provides a possible implementation:


- http://www.cmake.org/pipermail/cmake/2012-May/050292.html
- 
http://cmake.3232098.n2.nabble.com/CPack-DEB-depends-bug-fix-td7560635.html


My use case is the following:
- I have several components, each of which creating one specific .deb
- I have dependencies across components (let's say python extensions 
depends on core). Right now if I am not mistaken, the 
CPACK_COMPONENT_COMP_DEPENDS is not handled with the debian packaging

- The dependencies are not the same for each of the components.


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

Best,
Raffi Enficiaud



--

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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

[Raffi Enficiaud]

Le 16/04/15 14:55, Domen Vrankar a écrit :

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.


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





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?


Sure! I assigned the issue to myself. Let's see how it goes.

Best,
Raffi


--

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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

[Raffi Enficiaud]

Le 16/04/15 15:54, Raffi Enficiaud a écrit :

Le 16/04/15 14:55, Domen Vrankar a écrit :

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.


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




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?


Sure! I assigned the issue to myself. Let's see how it goes.



I am right now testing the cmake 3.2 based on master. Before that I had 
a code running ok-kind-of with the default cmake of ubuntu 14.04 (2.8.12.2).


When I create the debian with components for the two versions of cmake 
with the same source tree, (option CPACK_DEB_PACKAGE_COMPONENTS)

- I can see the packages generated with 2.8.12.1
- I cannot see the packages generated with 3.2.20150416-g53264
- Cmake 3.2 is generating a package with the files at incorrect 
destinations: for the component core-dev, the files will be installed on 
core-dev/usr/include/xxx, while for cmake 2.8.12, the destination path 
is urs/include/xxx


How can I have the previous behaviour with cmake 3.2?

Thanks,
Raffi

--

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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

[Raffi Enficiaud]

Le 16/04/15 16:45, Raffi Enficiaud a écrit :

Le 16/04/15 15:54, Raffi Enficiaud a écrit :

Le 16/04/15 14:55, Domen Vrankar a écrit :

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.


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




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?


Sure! I assigned the issue to myself. Let's see how it goes.



I am right now testing the cmake 3.2 based on master. Before that I had
a code running ok-kind-of with the default cmake of ubuntu 14.04
(2.8.12.2).

When I create the debian with components for the two versions of cmake
with the same source tree, (option CPACK_DEB_PACKAGE_COMPONENTS)
- I can see the packages generated with 2.8.12.1
- I cannot see the packages generated with 3.2.20150416-g53264
- Cmake 3.2 is generating a package with the files at incorrect
destinations: for the component core-dev, the files will be installed on
core-dev/usr/include/xxx, while for cmake 2.8.12, the destination path
is urs/include/xxx

How can I have the previous behaviour with cmake 3.2?

Thanks,
Raffi



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

I can read A component does not have to belong to any component GROUP.

I checked the tests for that, and I think they do not cover that case 
since the groups are defined there.




Any suggestions?
Best,
Raffi




--

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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] Introduction and volunteering for the Matlab package

[Raffi Enficiaud]

 On 17 Mar 2015, at 19:39, Brad King brad.k...@kitware.com wrote:
 
 On 03/17/2015 12:28 PM, Raffi Enficiaud wrote:
 I think everything in http://www.cmake.org/Bug/view.php?id=14641 was 
 addressed.
 What should the maintainer usually do?
 
 I've marked your Mantis account as a developer for CMake and assigned
 the issue to you.  In this case since it's already resolved I went ahead
 and marked the issue as such already.  Future issues with this module may
 be assigned to you.
 
 Thanks,
 -Brad
 

Very good, and many thanks for your support,

Best,
Raffi

-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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] Introduction and volunteering for the Matlab package

[Raffi Enficiaud]

Le 12/03/15 21:00, Brad King a écrit :

On 03/12/2015 12:35 PM, Raffi Enficiaud wrote:

I will squash all this together once everything is done.
For now please base further work on commit 3743aa11.
We'll see how this does on the nightly testing!



Hi,

I have a problem running the tests on win7. All the tests are passing, 
but at the end, I have the following:


17-Mar-2015 04:23:23100% tests passed, 0 tests failed out of 21
17-Mar-2015 04:23:23
17-Mar-2015 04:23:23Total Test time (real) =  21.84 sec
17-Mar-2015 04:23:23 	Add file: 
D:/bamboo_build_dir/SW-CMAK-JOB1/dashboard/CMakeScripts/findmatlab_nightbuild.cmake
17-Mar-2015 04:23:23 	Add file: 
D:/bamboo_build_dir/SW-CMAK-JOB1/dashboard/CMakeScripts/cmake_common.cmake
17-Mar-2015 04:23:23 	Add file: 
D:/bamboo_build_dir/SW-CMAK-JOB1/dashboard/CMakeScripts/findmatlab_nightbuild.cmake
17-Mar-2015 04:23:23 	Add file: 
D:/bamboo_build_dir/SW-CMAK-JOB1/dashboard/CMakeScripts/kwsys_common.cmake

17-Mar-2015 04:23:23Submit files (using http)
17-Mar-2015 04:23:23   Using HTTP submit method
17-Mar-2015 04:23:23 	   Drop 
site:http://open.cdash.org/submit.php?project=KWSys
17-Mar-2015 04:23:40 	   Uploaded: 
D:/bamboo_build_dir/SW-CMAK-JOB1/dashboard/My 
Tests/KWSys-build/Testing/20150317-0100/Build.xml
17-Mar-2015 04:23:44 	   Uploaded: 
D:/bamboo_build_dir/SW-CMAK-JOB1/dashboard/My 
Tests/KWSys-build/Testing/20150317-0100/Configure.xml
17-Mar-2015 04:23:49 	   Uploaded: 
D:/bamboo_build_dir/SW-CMAK-JOB1/dashboard/My 
Tests/KWSys-build/Testing/20150317-0100/Notes.xml
17-Mar-2015 04:23:53 	   Uploaded: 
D:/bamboo_build_dir/SW-CMAK-JOB1/dashboard/My 
Tests/KWSys-build/Testing/20150317-0100/Test.xml
17-Mar-2015 04:23:56 	   Uploaded: 
D:/bamboo_build_dir/SW-CMAK-JOB1/dashboard/My 
Tests/KWSys-build/Testing/20150317-0100/Update.xml

17-Mar-2015 04:23:56   Submission successful
17-Mar-2015 04:23:57 	Error in read script: 
D:/bamboo_build_dir/SW-CMAK-JOB1/dashboard/CMakeScripts/findmatlab_nightbuild.cmake
17-Mar-2015 04:23:57 	Failing task since return code of [C:\Program 
Files (x86)\CMake 2.8\bin\ctest.exe -S findmatlab_nightbuild.cmake -V] 
was -1 while expected 0



The content of the findmatlab_nightbuild.cmake is

set(CTEST_SITE bambooagent.raffienficiaud)
set(CTEST_BUILD_NAME Win7x64-vs2013e-matlab2013b)
set(CTEST_BUILD_CONFIGURATION Debug)
set(CTEST_CMAKE_GENERATOR Visual Studio 12 Win64)

set(dashboard_cache CMake_TEST_FindMatlab:BOOL=ON)
include(${CTEST_SCRIPT_DIRECTORY}/cmake_common.cmake)

and I am using ctest 2.8.12 to run -S findmatlab_nightbuild.cmake -V

Any clue?

Raffi

--

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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] Introduction and volunteering for the Matlab package

[Raffi Enficiaud]

 On 17 Mar 2015, at 16:25, Brad King brad.k...@kitware.com wrote:
 
 Nothing right now!  I've squashed this all into one commit:
 
 FindMatlab: Rewrite module and provide a usage API
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=49c8dcf7
 
 and merged to 'master' for inclusion in 3.3.
 
 Thanks for all your work on this and persistence with following up
 on feedback.  This is a huge improvement over the previous FindMatlab
 module.
 
 -Brad

I am happy that it worked! 
I think everything in http://www.cmake.org/Bug/view.php?id=14641 was addressed.
What should the maintainer usually do?

Best,
Raffi
-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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] Introduction and volunteering for the Matlab package

[Raffi Enficiaud]

Le 12/03/15 21:00, Brad King a écrit :

On 03/12/2015 12:35 PM, Raffi Enficiaud wrote:

* Renamed one more MATLAB_USER_ROOT = Matlab_ROOT_DIR
* Do not call list(REMOVE_DUPLICATES/SORT/REVERSE) with no list


Thanks!



The commits are now:

  FindMatlab: Rewrite module and provide a usage API
  http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=3c025a5f

  FindMatlab: Further revisions
  http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=842ab109

  FindMatlab: Further revisions
  http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=3743aa11

I will squash all this together once everything is done.
For now please base further work on commit 3743aa11.
We'll see how this does on the nightly testing!


A test is failing on win32 but I to not think it is due to the FindMatlab:
https://open.cdash.org/testDetails.php?test=319823202build=3731585

What other changes are needed?

Best,
Raffi


--

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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] Introduction and volunteering for the Matlab package

[Raffi Enficiaud]

Le 11/03/15 00:12, Raffi Enficiaud a écrit :

Hi Brad,

Please find the attached patch addressing the issues. In the current
implementation, if the Matlab_ROOT_DIR is changed by the user, the
cached variables are all cleared.
Also, Matlab_ROOT_DIR is now the only variable that is seen as non
advanced.

Best,
Raffi



Hi Brad,

The attached patch replaces the previous one: now the versions on 
Windows are ordered starting the most recent (+ an ugly remaining 
FATAL_ERROR debug).



Best,
Raffi

From bca63b3669366d3d2db4438efe91c58d3a82fc40 Mon Sep 17 00:00:00 2001
From: Raffi Enficiaud raffi.enfici...@tuebingen.mpg.de
Date: Thu, 12 Mar 2015 17:08:44 +0100
Subject: [PATCH] * Simplified workflow, better isolation of the code when
 Matlab is to be found from the PATH * Removing the which matlab as the
 find_program was erroneous * MATLAB_USER_ROOT renamed to Matlab_ROOT_DIR,
 which now reflects the found root, removed Matlab_ROOT * Reduced the number
 of find_program(matlab) * Nulled the input stream of the execute_process in
 order to avoid the troubleshooting with the terminal * Clearing all the
 cached variables in case the Matlab_ROOT_DIR is changed by the user * Marking
 all but Matlab_ROOT_DIR variable as advanced * Hiding all internal cache
 entries * Avoiding the computation of the version (Matlab_ROOT_DIR set) if
 the first pass produced the version automatically * Windows: now versions are
 ordered starting from the most recent

---
 Modules/FindMatlab.cmake   | 490 -
 Modules/MatlabTestsRedirect.cmake  |   8 +
 Tests/FindMatlab/cmake_matlab_unit_tests_timeout.m |   3 +-
 Tests/RunCMake/CMakeLists.txt  |   1 +
 4 files changed, 289 insertions(+), 213 deletions(-)

diff --git a/Modules/FindMatlab.cmake b/Modules/FindMatlab.cmake
index 9686a76..b61c620 100644
--- a/Modules/FindMatlab.cmake
+++ b/Modules/FindMatlab.cmake
@@ -28,14 +28,15 @@
 #   :command:`matlab_get_release_name_from_version` allow a mapping
 #   from the release name to the version.
 #
-# The variable :variable:`MATLAB_USER_ROOT` may be specified in order to give
+# The variable :variable:`Matlab_ROOT_DIR` may be specified in order to give
 # the path of the desired Matlab version. Otherwise, the behaviour is platform
 # specific:
 #
 # * Windows: The installed versions of Matlab are retrieved from the
 #   Windows registry
 # * OS X: The installed versions of Matlab are given by the MATLAB
-#   paths in ``/Application``
+#   paths in ``/Application``. If no such application is found, it falls back 
+#   to the one that might be accessible from the PATH.
 # * Unix: The desired Matlab should be accessible from the PATH.
 #
 # Additional information is provided when :variable:`MATLAB_FIND_DEBUG` is set.
@@ -59,7 +60,7 @@
 # Users or projects may set the following variables to configure the module
 # behaviour:
 #
-# :variable:`MATLAB_USER_ROOT`
+# :variable:`Matlab_ROOT_DIR`
 #   the root of the Matlab installation.
 # :variable:`MATLAB_FIND_DEBUG`
 #   outputs debug information
@@ -77,14 +78,15 @@
 #   ``TRUE`` if the Matlab installation is found, ``FALSE``
 #   otherwise. All variable below are defined if Matlab is found.
 # ``Matlab_ROOT_DIR``
-#   the root of the Matlab installation determined by the FindMatlab module.
+#   the final root of the Matlab installation determined by the FindMatlab 
+#   module.
 # ``Matlab_MAIN_PROGRAM``
 #   the Matlab binary program. Available only if the component ``MAIN_PROGRAM``
 #   is given in the :command:`find_package` directive.
 # ``Matlab_INCLUDE_DIRS``
 #  the path of the Matlab libraries headers
 # ``Matlab_MEX_LIBRARY``
-#   library for mex
+#   library for mex, always available.
 # ``Matlab_MX_LIBRARY``
 #   mx library of Matlab (arrays). Available only if the component
 #   ``MX_LIBRARY`` has been requested.
@@ -102,6 +104,9 @@
 #
 # ``Matlab_MEX_EXTENSION``
 #   the extension of the mex files for the current platform (given by Matlab).
+# ``Matlab_ROOT_DIR``
+#   the location of the root of the Matlab installation found. If this value
+#   is changed by the user, the result variables are recomputed.
 #
 # Provided macros
 # ---
@@ -162,10 +167,11 @@
 # Reference
 # --
 #
-# .. variable:: MATLAB_USER_ROOT
+# .. variable:: Matlab_ROOT_DIR
 #
-#The root folder of the Matlab installation. This is set before the call to
-#:command:`find_package`. If not set, then an automatic search of Matlab
+#The root folder of the Matlab installation. If set before the call to
+#:command:`find_package`, the module will look for the components in that
+#path. If not set, then an automatic search of Matlab
 #will be performed. If set, it should point to a valid version of Matlab.
 #
 # .. variable:: MATLAB_FIND_DEBUG
@@ -176,7 +182,6 @@
 # .. variable:: MATLAB_ADDITIONAL_VERSIONS
 #
 #   If set, specifies additional versions of Matlab that may be looked for.
-#   This variable

Re: [cmake-developers] Introduction and volunteering for the Matlab package

[Raffi Enficiaud]

Le 26/02/15 21:32, Brad King a écrit :

On 02/26/2015 03:23 PM, Raffi Enficiaud wrote:
We never specified explicitly which name to use.  I think it
should be Matlab_ROOT_DIR because that makes sense whether the
user specified it or not.


Right, so I made the changes and updated the documentation. A kind 
person tested my module and proposed to change the behaviour in order to 
be able to change the Matlab_ROOT_DIR after the first configuration The 
workflow would be:

- I start without Matlab_ROOT_DIR,
- Matlab_ROOT_DIR is automatically determined,
- I change Matlab_ROOT_DIR

I am expecting all dependent variables (cached or not) be updated to 
reflect this change. Apparently this is something that is done in eg. 
wxWidget.


The question is: should also this be implemented? The way I am seeing 
this is to clear all variables when another Matlab_ROOT_DIR than the 
cached/internal one is set.



We shouldn't have to disable the test.  It can still be an
error for the MAIN_PROGRAM component to not be requested.
You can separate the name of the cache variable used as
the one search for matlab from the name of the result
variable used to provide the MAIN_PROGRAM component.  That
will be consistent with the view that finding matlab is
an implementation detail on some platforms even when the
MAIN_PROGRAM component is not requested.

Please revise this patch further for the above.


Will do. Another question: may the test be dependent on a particular 
site? For instance, on one of the builders, I have several versions of 
Matlab. Is testing against the current build site something that would 
be acceptable?


Best,
Raffi

--

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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] Introduction and volunteering for the Matlab package

[Raffi Enficiaud]

Le 10/03/15 14:34, Brad King a écrit :

On 03/10/2015 09:08 AM, Raffi Enficiaud wrote:

- I change Matlab_ROOT_DIR

I am expecting all dependent variables (cached or not) be updated

The question is: should also this be implemented?


Yes.  See the FindBoost module for similar behavior with respect to
the library directory.


Will do. Another question: may the test be dependent on a particular
site? For instance, on one of the builders, I have several versions of
Matlab. Is testing against the current build site something that would
be acceptable?


The per-site information should not be hard-coded in the source tree.
However, you can use cache entries to hold the local configuration.

-Brad



Hi Brad,

Please find the attached patch addressing the issues. In the current 
implementation, if the Matlab_ROOT_DIR is changed by the user, the 
cached variables are all cleared.

Also, Matlab_ROOT_DIR is now the only variable that is seen as non advanced.

Best,
Raffi

From 4f73bd38849a67ef4e677e223fbb43af9d09f976 Mon Sep 17 00:00:00 2001
From: Raffi Enficiaud raffi.enfici...@tuebingen.mpg.de
Date: Wed, 11 Mar 2015 00:08:42 +0100
Subject: [PATCH] * Simplified workflow, better isolation of the code when
 Matlab is to be found from the PATH * Removing the which matlab as the
 find_program was erroneous * MATLAB_USER_ROOT renamed to Matlab_ROOT_DIR,
 which now reflects the found root, removed Matlab_ROOT * Reduced the number
 of find_program(matlab) * Nulled the input stream of the execute_process in
 order to avoid the troubleshooting with the terminal * Clearing all the
 cached variables in case the Matlab_ROOT_DIR is changed by the user * Marking
 all but Matlab_ROOT_DIR variable as advanced * Hiding all internal cache
 entries * Avoiding the computation of the version (Matlab_ROOT_DIR set) if
 the first pass produced the version automatically

---
 Modules/FindMatlab.cmake   | 487 -
 Modules/MatlabTestsRedirect.cmake  |   8 +
 Tests/FindMatlab/cmake_matlab_unit_tests_timeout.m |   3 +-
 Tests/RunCMake/CMakeLists.txt  |   1 +
 4 files changed, 286 insertions(+), 213 deletions(-)

diff --git a/Modules/FindMatlab.cmake b/Modules/FindMatlab.cmake
index 9686a76..c637df4 100644
--- a/Modules/FindMatlab.cmake
+++ b/Modules/FindMatlab.cmake
@@ -28,14 +28,15 @@
 #   :command:`matlab_get_release_name_from_version` allow a mapping
 #   from the release name to the version.
 #
-# The variable :variable:`MATLAB_USER_ROOT` may be specified in order to give
+# The variable :variable:`Matlab_ROOT_DIR` may be specified in order to give
 # the path of the desired Matlab version. Otherwise, the behaviour is platform
 # specific:
 #
 # * Windows: The installed versions of Matlab are retrieved from the
 #   Windows registry
 # * OS X: The installed versions of Matlab are given by the MATLAB
-#   paths in ``/Application``
+#   paths in ``/Application``. If no such application is found, it falls back 
+#   to the one that might be accessible from the PATH.
 # * Unix: The desired Matlab should be accessible from the PATH.
 #
 # Additional information is provided when :variable:`MATLAB_FIND_DEBUG` is set.
@@ -59,7 +60,7 @@
 # Users or projects may set the following variables to configure the module
 # behaviour:
 #
-# :variable:`MATLAB_USER_ROOT`
+# :variable:`Matlab_ROOT_DIR`
 #   the root of the Matlab installation.
 # :variable:`MATLAB_FIND_DEBUG`
 #   outputs debug information
@@ -77,14 +78,15 @@
 #   ``TRUE`` if the Matlab installation is found, ``FALSE``
 #   otherwise. All variable below are defined if Matlab is found.
 # ``Matlab_ROOT_DIR``
-#   the root of the Matlab installation determined by the FindMatlab module.
+#   the final root of the Matlab installation determined by the FindMatlab 
+#   module.
 # ``Matlab_MAIN_PROGRAM``
 #   the Matlab binary program. Available only if the component ``MAIN_PROGRAM``
 #   is given in the :command:`find_package` directive.
 # ``Matlab_INCLUDE_DIRS``
 #  the path of the Matlab libraries headers
 # ``Matlab_MEX_LIBRARY``
-#   library for mex
+#   library for mex, always available.
 # ``Matlab_MX_LIBRARY``
 #   mx library of Matlab (arrays). Available only if the component
 #   ``MX_LIBRARY`` has been requested.
@@ -102,6 +104,9 @@
 #
 # ``Matlab_MEX_EXTENSION``
 #   the extension of the mex files for the current platform (given by Matlab).
+# ``Matlab_ROOT_DIR``
+#   the location of the root of the Matlab installation found. If this value
+#   is changed by the user, the result variables are recomputed.
 #
 # Provided macros
 # ---
@@ -162,10 +167,11 @@
 # Reference
 # --
 #
-# .. variable:: MATLAB_USER_ROOT
+# .. variable:: Matlab_ROOT_DIR
 #
-#The root folder of the Matlab installation. This is set before the call to
-#:command:`find_package`. If not set, then an automatic search of Matlab
+#The root folder of the Matlab installation. If set before the call

Re: [cmake-developers] Introduction and volunteering for the Matlab package

[Raffi Enficiaud]

Quick question:
Is it possible to redirect the input stream of execute_process from /dev/null 
on OSX and Linux ?
Right now on these platforms, I need to reset my shell. If I run the ctest 
command with  /dev/null, everything is fine. So my guess is that Matlab is 
manipulating the console somehow.

Thanks,
Raffi

 On 26 Feb 2015, at 18:02, Raffi Enficiaud raffi.enfici...@free.fr wrote:
 
 Hi Brad,
 
 Please find the patch addressing the issues you raised. My local tests are 
 clear on the 3 platforms.
 I removed the RunCMake test on Linux as now the Matlab_MAIN_PROGRAM is 
 required if MATLAB_USER_ROOT is not specified. In the previous 
 implementation, I used temporary variables to avoid bringing this program to 
 the user.
 
 Any feedback welcome,
 
 Best,
 Raffi
 
 0001-Simplified-workflow.patch
 On 25 Feb 2015, at 14:32, Brad King brad.k...@kitware.com wrote:
 
 On 02/25/2015 04:11 AM, Raffi Enficiaud wrote:
 Is it ok if I rebase on 1416d21?
 
 Yes, please.
 
 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

-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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] Introduction and volunteering for the Matlab package

[Raffi Enficiaud]

Hi Brad,

Please find the patch addressing the issues you raised. My local tests are 
clear on the 3 platforms.
I removed the RunCMake test on Linux as now the Matlab_MAIN_PROGRAM is required 
if MATLAB_USER_ROOT is not specified. In the previous implementation, I used 
temporary variables to avoid bringing this program to the user.

Any feedback welcome,

Best,
Raffi



0001-Simplified-workflow.patch
Description: Binary data

 On 25 Feb 2015, at 14:32, Brad King brad.k...@kitware.com wrote:
 
 On 02/25/2015 04:11 AM, Raffi Enficiaud wrote:
 Is it ok if I rebase on 1416d21?
 
 Yes, please.
 
 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] Introduction and volunteering for the Matlab package

[Raffi Enficiaud]

Thanks! here is the patch then, replacing the previous one, rebased on 
1416d214b3.

Best,
Raffi



0001-Simplified-workflow.patch
Description: Binary data

 On 26 Feb 2015, at 18:52, Brad King brad.k...@kitware.com wrote:
 
 On 02/26/2015 12:06 PM, Raffi Enficiaud wrote:
 Is it possible to redirect the input stream of execute_process
 from /dev/null on OSX and Linux ?
 
 Yes:
 
  INPUT_FILE /dev/null
 
 and on Windows:
 
  INPUT_FILE NUL
 
 -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] Introduction and volunteering for the Matlab package

[Raffi Enficiaud]

Hi Brad,

Thanks, I started addressing the issues, hopefully I will finish today. Is it 
ok if I rebase on 1416d21?

Best,
Raffi

 On 23 Feb 2015, at 18:54, Brad King brad.k...@kitware.com wrote:
 
 Hi Raffi,
 
 Your matlab-enabled nightly builds have been clean for a few days on all
 the platforms.  I've moved them to the Nightly Expected section of the
 dashboard.
 
 Now I'm just waiting on your next updates to the module based on my
 comments elsewhere in this thread to proceed with the FindMatlab
 topic.
 
 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] Introduction and volunteering for the Matlab package

[Raffi Enficiaud]

 On 19 Feb 2015, at 18:52, Brad King brad.k...@kitware.com wrote:
 
 On 02/19/2015 11:54 AM, Raffi Enficiaud wrote:
 On the system I am working, matlab in the PATH is a symlink with
 r  x permissions
 [snip]
 Is there any internal in the find_program to check what conditions
 are not met?
 
 What are the permissions of the underlying file after resolving
 the link?  The find_program command wants r permission, and it
 always unwraps symlinks.

If I continue the chain:
renficiaud@madeira3:~$ ls -al /etc/alternatives/matlab
lrwxrwxrwx 1 root root 43 Oct 20 15:32 /etc/alternatives/matlab - 
/is/software/matlab/linux/R2014a/bin/matlab
renficiaud@madeira3:~$ ls -al /is/software/matlab/linux/R2014a/bin/matlab
-r-xr-xr-x 1 stark is 55331 Dec 27  2013 
/is/software/matlab/linux/R2014a/bin/matlab

r permission are definitively there and the user is allowed to run this command.
BTW, I cannot see in the documentation that find_program unwraps symlinks. By 
myself, I explained the observed behaviour as find_program being blind to 
symlinks.


 
 you propose to merge the variables MATLAB_USER_ROOT and
 Matlab_ROOT_DIR, is that correct?
 
 Yes.  Furthermore, if we can always compute the other information
 from that value then as little of it should be cached as possible.
 

Ok, will do then.

-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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] Introduction and volunteering for the Matlab package

[Raffi Enficiaud]

Please find attached the merge of the two previous patches, rebased on 5dae6cf.

Thanks,
Raffi Enficiaud



0001-Adding-R2014a.patch
Description: Binary data


 On 19 Feb 2015, at 12:49, Raffi Enficiaud raffi.enfici...@free.fr wrote:
 
 Dear Brad,
 
 Apparently there are some issues when things are running with the dashboard, 
 which I did not observed yesterday.
 Those issues are related to the space in the test folder in the dashboard, 
 which I did not see on my local computer.
 
 The attached patch (based on 5dae6cf) should solve those issues (tested only 
 in the dashboard folder of the ubuntu version). 
 
 0001-Fixing-problems-related-to-spaces-in-directory-names.patch
 
 Thanks,
 Raffi
 
 
 
 On 18 Feb 2015, at 23:11, Raffi Enficiaud raffi.enfici...@free.fr wrote:
 
 Please find attached the patch addressing the issues + some others, rebased 
 against 5dae6cf. 
 I tested it on the 3 target platforms.
 
 patch.diff
 
 On 18 Feb 2015, at 15:13, Brad King brad.k...@kitware.com wrote:
 
 On 02/17/2015 07:28 PM, Raffi Enficiaud wrote:
 The tests were failing because of the following modification:
 
 -  matlab_get_version_from_matlab_run(${Matlab_MAIN_PROGRAM} 
 matlab_list_of_all_versions)
 +  matlab_get_version_from_matlab_run(${Matlab_MAIN_PROGRAM} 
 matlab_list_of_all_versions)
 
 Apparently the quotes here are interpreted as part of the binary name,
 which prevents the proper call to matlab using the execute_process 
 function.
 
 That should not be possible.  The quotes are needed in case the variable
 value is an empty string.  They will not be treated as part of the value
 passed to the function argument.
 
 I restored the quotes. Maybe I experienced a caching issue: I run ctest with 
 FindMatlab regex, and from time to time the cache is messed while I am 
 working and I do not clean the folders systematically. 
 
 
 
 I kept the symlink resolution, but I narrowed the case those should be
 resolved. I added a variable pointing to the (symlink resolved) location
 of the binary from which the version is retrieved.
 
 Yes, thanks.
 
 I squashed the changes into 9d414ca2 and rebased again.  Everything
 so far is now in:
 
 FindMatlab: Rewrite module and provide a usage API
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5dae6cfc
 
 and merged to 'next' for testing.  Please base fixes for the below
 on that.
 
 Couple of questions:
 - does the script of the dashboard clean the folders? Or I have to do that 
 manually? (cf caching issues above)
 - is it the next branch that is tested on the nightly section of the 
 dashboard? 
 
 
 More comments:
 
 Why do you need so many different find_program calls for matlab?
 There should be exactly one for Matlab_MAIN_PROGRAM, and it does
 not need to be guarded by if(NOT Matlab_MAIN_PROGRAM) because
 find_program does that already.  Any symlink resolution can be
 done on the result.
 
 I wanted to separate the parts in some kind of modules.
 
 - The first part is supposed to output the Matlab_ROOT and nothing else, and 
 the other parts are relying on that. Finding a matlab_program is an 
 implementation detail, which is not cross platform. Yet, the method is 
 kind of robust to find a proper installation ROOT. 
 
 - The second part deals with the version, in case we have no other way than 
 from asking Matlab. Since at this point, we have a ROOT, either given by the 
 user or from the first part, we search for the matlab program using this 
 information alone. In case the user gave the ROOT but not the version, we 
 still have to find the program under this ROOT. In case the user gave 
 nothing, we have to find the ROOT and the version, the former maybe implying 
 a matlab_program search. Again, I think this is an implementation detail 
 that the second part should not rely on.
 
 - The third part is the user facing matlab_program, that we find on demand.
 
 I agree this can be optimized in terms of find_program calls, but I would 
 like to keep this structure for finding in the appropriate sequence all the 
 information needed by the module. 
 
 The symlink resolutions are made on the appropriate places now.
 
 
 The get_filename_component(PROGRAM) mode is intended to take a
 command line string and figure out which leading piece is an
 existing program in case it is an unquoted path with spaces.
 While it may be a bug that this can return a directory, there
 should be no use case for this functionality in FindMatlab.
 
 I did not understood that from the documentation (the program in filename 
 will be found in the system search path): I thought it was another way of 
 finding programs. I removed the corresponding lines.
 
 
 
 # list the keys under HKEY_LOCAL_MACHINE\SOFTWARE\mathworks but the call to
 # reg does not work from cmake, curiously, as is. The command provides the
 # desired result under the command line though.
 # Fix: this is because /reg:64 should appended to the command, otherwise
 # it gets on the 32 bits software key (curiously

Re: [cmake-developers] Introduction and volunteering for the Matlab package

[Raffi Enficiaud]

Ok, I thought this was for the ctest program that accepts -j flag. I will do 
the change, I am running the build already with all the // flags removed.

Thanks,
Raffi

 On 19 Feb 2015, at 15:17, Brad King brad.k...@kitware.com wrote:
 
 On 02/19/2015 06:49 AM, Raffi Enficiaud wrote:
 Apparently there are some issues when things are running with the dashboard
 
 For the Visual Studio build on your Windows machine you have:
 
 set(CTEST_BUILD_FLAGS -j4)
 
 which is not a valid msbuild flag.  For that you could use
 
 set(CTEST_BUILD_FLAGS -m4)
 
 instead.
 
 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] Introduction and volunteering for the Matlab package

[Raffi Enficiaud]

 On 19 Feb 2015, at 14:53, Brad King brad.k...@kitware.com wrote:
 
 On 02/19/2015 08:39 AM, Raffi Enficiaud wrote:
 Please find attached the merge of the two previous patches, rebased on 
 5dae6cf.
 
 Applied, thanks:
 
 FindMatlab: Further revisions
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1416d214
 
Thanks.

 Those issues are related to the space in the test folder in the dashboard
 
 Quoting of arguments in the cmake language:
 
 http://www.cmake.org/cmake/help/v3.2/manual/cmake-language.7.html#command-arguments
 
 is not necessary to deal with spaces that are not literally written in
 the argument.  Separation of unquoted arguments after variable evaluation
 only happens on ;.  However, any unnecessary quoting you added also
 won't hurt anything and makes it easier to read anyway.

Good then. Matlab supports not very well spaces in the log file name, I suppose 
that if I do
execute_process(COMMAND matlab -logfile some path with spaces)
this is correctly escaped by cmake.

 
 Returning to a previous comment:
 
 On 02/18/2015 09:13 AM, Brad King wrote:
 Why do you need so many different find_program calls for matlab?
 There should be exactly one for Matlab_MAIN_PROGRAM
 
 I still see four places that try to find matlab, quoted below.
 It looks like you're trying to make Matlab_MAIN_PROGRAM defined
 if the MAIN_PROGRAM component was requested.

Relates to my previous answer on this topic.

 
  find_program(
_matlab_main_tmp
NAMES matlab)
 
  if(NOT _matlab_main_tmp)
execute_process(
  COMMAND which matlab
  OUTPUT_VARIABLE _matlab_main_tmp
  ERROR_VARIABLE _matlab_main_tmp_err)
# the output should be cleaned up
string(STRIP ${_matlab_main_tmp} _matlab_main_tmp)
  endif()
 
 If find_program doesn't find it, which won't have better luck.

Which is also what I thought but this is factually incorrect. I tested that 
yesterday on a regular LTS14.04 server. find_program fails while which matlab 
does not.

 
  if(Matlab_MAIN_PROGRAM)
set(_matlab_main_tmp ${Matlab_MAIN_PROGRAM})
  else()
find_program(
  _matlab_main_tmp
  matlab
  PATHS ${Matlab_ROOT_DIR} ${Matlab_ROOT_DIR}/bin
  DOC Matlab main program
  NO_DEFAULT_PATH
)
  endif()
 
 We should not risk finding the wrong matlab here.  See below.
 
  # todo cleanup with code above
  if(NOT DEFINED Matlab_MAIN_PROGRAM)
find_program(
  Matlab_MAIN_PROGRAM
  matlab
  PATHS ${Matlab_ROOT_DIR} ${Matlab_ROOT_DIR}/bin
  DOC Matlab main program
  NO_DEFAULT_PATH
)
  endif()
 
 This looks like the component-specific search.  If we are to present
 a component-specific result variable name then it can simply be
 populated from the one true location found.

In the code just above, the if() condition is not needed anymore since now 
there is no aliasing with the previous searches. I'll fix that.
On Windows, we have the Matlab_ROOT and the version from the registry, so we 
need to run find_program there. On OSX, if the previous find_program or which 
matlab did not result in anything relevant, we parse the 
/Application/MATLAB_xxx folders so we end up with a root and a version without 
a main_program, so the find_program above is also needed.

 
 If matlab is needed to compute information for other components
 then finding it should not be optional.  There should be a single
 
 find_program(Matlab_EXECUTABLE ...)
 
 whose result is cached and re-used everywhere that matlab is
 needed.  Separate symlink-resolving on it can be done when needed
 but does not need to be cached.

I agree with that, but this behaviour is not consistent across every platforms. 
My preference goes to the kind of modular approach currently implemented in the 
module, which is:
1- find all possible matlab roots with the tools provided by the system, or 
just stick to the user input
2- for each or one of them, find the version if information is lacking
3- return the one that fits best to the find_matlab options

Finding the matlab program from time to time is for me an implementation 
detail: examples
- if the user give the Matlab_ROOT, the version is lacking, I then need to find 
matlab in the second step. 
- if the user gave no input, I need to find Matlab in the first step, 
conditionally on the platform, to extract Matlab_ROOT (and not to find matlab 
itself). I then run the find_matlab in the second step conditionally on the 
platform again. In the third step, I gather all the information I have so far, 
which is the intersection for all platforms: MatlabROOT and MatlabVERSION. 
- on win32, if there is not user defined Matlab_ROOT, we have the root and 
version from the registry, there is only the last component oriented 
find_program running, only if required by the user.

Also the main functionality is not performance oriented. Caching is in fact an 
undesirable side-effect for what I want to achieve. While finding matlab is 
certainly not optimal

Re: [cmake-developers] Introduction and volunteering for the Matlab package

[Raffi Enficiaud]

 On 19 Feb 2015, at 22:24, Brad King brad.k...@kitware.com wrote:
 
 On 02/19/2015 04:15 PM, Raffi Enficiaud wrote:
 renficiaud@madeira3:~$ ls -al /is/software/matlab/linux/R2014a/bin/matlab
 -r-xr-xr-x 1 stark is 55331 Dec 27  2013 
 /is/software/matlab/linux/R2014a/bin/matlab
 
 r permission are definitively there and the user is allowed to run this 
 command.
 
 Hmm.  See if you can reproduce it with something simple like:
 
 [snip]

I cannot reproduce with this simple example. However, on next, I did that (line 
990):

 find_program(
_matlab_main_tmp 
NAMES matlab)
  message(FATAL_ERROR is find matlab correct? ${_matlab_main_tmp})

The error message is

CMake Error at /is/ps2/renficiaud/Code/CMake/Modules/FindMatlab.cmake:993 
(message):
  is find matlab correct?
Call Stack (most recent call first):
  CMakeLists.txt:11 (find_package)


Then I did that:

 find_program(
matlab_main_tmp 
NAMES matlab)
  message(FATAL_ERROR is find matlab correct? ${matlab_main_tmp})

and the error message is 

CMake Error at /is/ps2/renficiaud/Code/CMake/Modules/FindMatlab.cmake:993 
(message):
  is find matlab correct? /usr/bin/matlab
Call Stack (most recent call first):
  CMakeLists.txt:11 (find_package)


The functionality works then, there is something else with the variable itself. 
Some lines before I uses the same variable name

set(_matlab_main_tmp )

I just unset this variable before the call to the find_program, and now it 
works good. Basically the variable is not overwritten, maybe because another 
one is created in the cache?
Any hint? Known behaviour?

I'll do the fix and remove the which matlab then (so we dropped the # of 
find matlab from 4 to 2 in one day).

Best,
Raffi

-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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] Introduction and volunteering for the Matlab package

[Raffi Enficiaud]

 On 19 Feb 2015, at 16:48, Brad King brad.k...@kitware.com wrote:
 
 On 02/19/2015 10:20 AM, Raffi Enficiaud wrote:
 If find_program doesn't find it, which won't have better luck.
 
 I tested that yesterday on a regular LTS14.04 server. find_program
 fails while which matlab does not.
 
 Please figure out why find_program fails so we can fix it rather
 than working around it with which.  The find_program command
 searches the PATH just like which does.  Is matlab one of
 those executables with x permission but not r permission?

On the system I am working, matlab in the PATH is a symlink with r  x 
permissions

renficiaud@madeira3:~/Code/CMake$ which matlab
/usr/bin/matlab
renficiaud@madeira3:~/Code/CMake$ ls -al /usr/bin/matlab
lrwxrwxrwx 1 root root 24 May 15  2013 /usr/bin/matlab - 
/etc/alternatives/matlab
renficiaud@madeira3:~/Code/CMake$ ls -al /etc/alternatives/matlab
lrwxrwxrwx 1 root root 43 Oct 20 15:32 /etc/alternatives/matlab - 
/is/software/matlab/linux/R2014a/bin/matlab
renficiaud@madeira3:~/Code/CMake$ echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games

Is there any internal in the find_program to check what conditions are not met?

 
 Finding the matlab program from time to time is for me an
 implementation detail
 
 Okay, I just wanted an explanation for why there are so many
 find_program calls for the same thing.  If the design is better
 that way then so be it.  However:
 
 Also the main functionality is not performance oriented.
 If I start trying to optimize all those calls, I would have
 complicated execution paths.
 
 Caching is not about performance.  It is about giving the user
 the opportunity to set the result explicitly when the automatic
 determination gets an undesired result.
 
 There needs to be at least (and ideally exactly) one cache
 entry that stores the location of matlab.  If the user sets it
 up front then great.  If not then we should search and store the
 result there for the user to accept or edit later.  Currently
 MATLAB_USER_ROOT allows the user to specify up front, but does
 not serve the second role.
 

If I understand correctly, you propose to merge the variables MATLAB_USER_ROOT 
and Matlab_ROOT_DIR, is that correct?
Or just drop Matlab_ROOT_DIR from the user view?

Best,
Raffi


-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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] Introduction and volunteering for the Matlab package

[Raffi Enficiaud]

Dear Brad,

I just tested the patch I sent you on OSX and Win32 and all the tests are clear.

Best,
Raffi Enficiaud


 On 18 Feb 2015, at 01:28, Raffi Enficiaud raffi.enfici...@free.fr wrote:
 
 Dear Brad,
 
 Please find attached a patch addressing the issues mentioned in your email.
 The tests were failing because of the following modification:
 
 -  matlab_get_version_from_matlab_run(${Matlab_MAIN_PROGRAM} 
 matlab_list_of_all_versions)
 +  matlab_get_version_from_matlab_run(${Matlab_MAIN_PROGRAM} 
 matlab_list_of_all_versions)
 
 Apparently the quotes here are interpreted as part of the binary name, which 
 prevents the proper call to matlab using the execute_process function.
 
 I kept the symlink resolution, but I narrowed the case those should be 
 resolved. I added a variable pointing to the (symlink resolved) location of 
 the binary from which the version is retrieved. I compare paths symlink 
 resolved for that purpose. I hope this is in line with what you would like to 
 have.
 
 Note that I only tested on LinuxLTS14.04 locally, I will test further 
 tomorrow morning. 
 I also changed the build path of the Windows agent, the build should be clear 
 on Windows now.
 
 Best regards,
 Raffi Enficiaud
 
 0001-Addressing-the-visibility-of-the-internal-variables-.patch
 On 13 Feb 2015, at 16:36, Brad King brad.k...@kitware.com wrote:
 
 On 02/13/2015 09:43 AM, Raffi Enficiaud wrote:
 * Why is Matlab_VERSION_STRING cached?  Shouldn't it be computed
 every time from the matlab that was found?
 
 In case the version is not found with an obvious method
 (on OSX /Applications/MATLABVersion, on Win32, the version also is
 given by the registry key), we have to find the version of matlab
 by running matlab itself. I am caching the version once I have it
 to prevent any further execution of matlab for retrieving this
 information.
 
 Okay.  Currently the value is user-facing, but it shouldn't ever be
 edited manually, right?  Instead the detected version could be cached
 in an INTERNAL cache entry.  Also there should be a second internal
 entry that records which matlab program was executed to compute the
 version.  If the latter does not match then the version should be
 re-computed.
 
 In case a symlink of the binary called matlab exists in /usr/local/bin
 for instance, I need to retrieve the path of the libraries mex, mx etc,
 that are relative to the real installation path of matlab.
 
 In that case I think you should look for those pieces relative to
 the original executable location first, and if not found then
 resolve symlinks into a temporary variable name and then use that.
 The resolved path should not be made user-facing so that any user
 that sets Matlab_MAIN_PROGRAM explicitly will see that value
 persist.
 
 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

-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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] Introduction and volunteering for the Matlab package

[Raffi Enficiaud]

Please find attached the patch addressing the issues + some others, rebased 
against 5dae6cf. 
I tested it on the 3 target platforms.



patch.diff
Description: Binary data


 On 18 Feb 2015, at 15:13, Brad King brad.k...@kitware.com wrote:
 
 On 02/17/2015 07:28 PM, Raffi Enficiaud wrote:
 The tests were failing because of the following modification:
 
 -  matlab_get_version_from_matlab_run(${Matlab_MAIN_PROGRAM} 
 matlab_list_of_all_versions)
 +  matlab_get_version_from_matlab_run(${Matlab_MAIN_PROGRAM} 
 matlab_list_of_all_versions)
 
 Apparently the quotes here are interpreted as part of the binary name,
 which prevents the proper call to matlab using the execute_process function.
 
 That should not be possible.  The quotes are needed in case the variable
 value is an empty string.  They will not be treated as part of the value
 passed to the function argument.

I restored the quotes. Maybe I experienced a caching issue: I run ctest with 
FindMatlab regex, and from time to time the cache is messed while I am 
working and I do not clean the folders systematically. 


 
 I kept the symlink resolution, but I narrowed the case those should be
 resolved. I added a variable pointing to the (symlink resolved) location
 of the binary from which the version is retrieved.
 
 Yes, thanks.
 
 I squashed the changes into 9d414ca2 and rebased again.  Everything
 so far is now in:
 
 FindMatlab: Rewrite module and provide a usage API
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5dae6cfc
 
 and merged to 'next' for testing.  Please base fixes for the below
 on that.

Couple of questions:
- does the script of the dashboard clean the folders? Or I have to do that 
manually? (cf caching issues above)
- is it the next branch that is tested on the nightly section of the 
dashboard? 

 
 More comments:
 
 Why do you need so many different find_program calls for matlab?
 There should be exactly one for Matlab_MAIN_PROGRAM, and it does
 not need to be guarded by if(NOT Matlab_MAIN_PROGRAM) because
 find_program does that already.  Any symlink resolution can be
 done on the result.

I wanted to separate the parts in some kind of modules.

- The first part is supposed to output the Matlab_ROOT and nothing else, and 
the other parts are relying on that. Finding a matlab_program is an 
implementation detail, which is not cross platform. Yet, the method is kind 
of robust to find a proper installation ROOT. 

- The second part deals with the version, in case we have no other way than 
from asking Matlab. Since at this point, we have a ROOT, either given by the 
user or from the first part, we search for the matlab program using this 
information alone. In case the user gave the ROOT but not the version, we still 
have to find the program under this ROOT. In case the user gave nothing, we 
have to find the ROOT and the version, the former maybe implying a 
matlab_program search. Again, I think this is an implementation detail that the 
second part should not rely on.

- The third part is the user facing matlab_program, that we find on demand.

I agree this can be optimized in terms of find_program calls, but I would 
like to keep this structure for finding in the appropriate sequence all the 
information needed by the module. 

The symlink resolutions are made on the appropriate places now.

 
 The get_filename_component(PROGRAM) mode is intended to take a
 command line string and figure out which leading piece is an
 existing program in case it is an unquoted path with spaces.
 While it may be a bug that this can return a directory, there
 should be no use case for this functionality in FindMatlab.

I did not understood that from the documentation (the program in filename will 
be found in the system search path): I thought it was another way of finding 
programs. I removed the corresponding lines.


 
  # list the keys under HKEY_LOCAL_MACHINE\SOFTWARE\mathworks but the call to
  # reg does not work from cmake, curiously, as is. The command provides the
  # desired result under the command line though.
  # Fix: this is because /reg:64 should appended to the command, otherwise
  # it gets on the 32 bits software key (curiously again)
 
 This is because the default registry view depends on which reg
 tool gets executed.  These comments do not belong in the final
 version of the module.

Yes, we exchanged on this point already. I removed the comments. Basically, at 
some point I thought it would have been useful to use cmake as a make that can 
run matlab commands through the matlab_program (and not obliged to link 
anything to it). This is not possible in the current state of the module, but 
would be possible readily in the future. BTW, I volunteered for the maintenance 
of the module, so I guess these would be future extensions.


 
  find_program(MATLAB_REG_EXE_LOCATION reg)
 
 Many projects just execute_process() the reg tool directly
 without finding it first.  It is reliably available on Windows.

Ok, I made

Re: [cmake-developers] Introduction and volunteering for the Matlab package

[Raffi Enficiaud]

Dear Brad,

Please find attached a patch addressing the issues mentioned in your email.
The tests were failing because of the following modification:

-  matlab_get_version_from_matlab_run(${Matlab_MAIN_PROGRAM} 
matlab_list_of_all_versions)
+  matlab_get_version_from_matlab_run(${Matlab_MAIN_PROGRAM} 
matlab_list_of_all_versions)

Apparently the quotes here are interpreted as part of the binary name, which 
prevents the proper call to matlab using the execute_process function.

I kept the symlink resolution, but I narrowed the case those should be 
resolved. I added a variable pointing to the (symlink resolved) location of the 
binary from which the version is retrieved. I compare paths symlink resolved 
for that purpose. I hope this is in line with what you would like to have.

Note that I only tested on LinuxLTS14.04 locally, I will test further tomorrow 
morning. 
I also changed the build path of the Windows agent, the build should be clear 
on Windows now.

Best regards,
Raffi Enficiaud



0001-Addressing-the-visibility-of-the-internal-variables-.patch
Description: Binary data

 On 13 Feb 2015, at 16:36, Brad King brad.k...@kitware.com wrote:
 
 On 02/13/2015 09:43 AM, Raffi Enficiaud wrote:
 * Why is Matlab_VERSION_STRING cached?  Shouldn't it be computed
 every time from the matlab that was found?
 
 In case the version is not found with an obvious method
 (on OSX /Applications/MATLABVersion, on Win32, the version also is
 given by the registry key), we have to find the version of matlab
 by running matlab itself. I am caching the version once I have it
 to prevent any further execution of matlab for retrieving this
 information.
 
 Okay.  Currently the value is user-facing, but it shouldn't ever be
 edited manually, right?  Instead the detected version could be cached
 in an INTERNAL cache entry.  Also there should be a second internal
 entry that records which matlab program was executed to compute the
 version.  If the latter does not match then the version should be
 re-computed.
 
 In case a symlink of the binary called matlab exists in /usr/local/bin
 for instance, I need to retrieve the path of the libraries mex, mx etc,
 that are relative to the real installation path of matlab.
 
 In that case I think you should look for those pieces relative to
 the original executable location first, and if not found then
 resolve symlinks into a temporary variable name and then use that.
 The resolved path should not be made user-facing so that any user
 that sets Matlab_MAIN_PROGRAM explicitly will see that value
 persist.
 
 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] Introduction and volunteering for the Matlab package

[Raffi Enficiaud]

Dear Brad,

Yes, thank you, you did well. 
And sorry for the delay, it takes more time than expected.

Best regards,
Raffi Enficiaud

 On 17 Feb 2015, at 16:16, Brad King brad.k...@kitware.com wrote:
 
 On 02/13/2015 10:57 AM, Brad King wrote:
 I had to add two commits to the topic to fix some continuous
 testing failures:
 
 Please rebase further work on commit 5e91eb43.  I will squash
 all this together later before merging to 'master'.
 
 After a few more fixes for other nightly testing failures I
 squashed all the changes into:
 
 FindMatlab: Rewrite module and provide a usage API
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9d414ca2
 
 On your nightly submissions all the tests are passing on Windows.
 However, all FindMatlab-related tests fail on the other platforms.
 I've reverted the whole topic from 'next' for now until you have
 time to address these failures.  Please base further patches on
 commit 9d414ca2.
 
 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] Introduction and volunteering for the Matlab package

[Raffi Enficiaud]

Hi,

3 build agents (lts14.04, osx10.9 and win7x64) are now running the nightly with 
the CMake_TEST_FindMatlab set to ON.
The site name is bambooagent.raffienficiaud @ 
https://open.cdash.org/viewSite.php?siteid=11851project=1currenttime=1423789200

Please let me know if there is anything else I should do.

Best regards,
Raffi Enficiaud


 On 12 Feb 2015, at 23:36, Raffi Enficiaud raffi.enfici...@free.fr wrote:
 
 
 On 12 Feb 2015, at 19:03, Brad King brad.k...@kitware.com wrote:
 
 
 The definition needs to be put in the cache of the CMake build itself,
 not passed to the ctest script.  To do that, add:
 
 set(dashboard_cache 
 CMake_TEST_FindMatlab:BOOL=ON
 )
 
 before including the common script.
 
 
 Good, I am trying this now. 
 
 - Is there any convention for CTEST_SITE? Would bambooagent.raffienficiaud 
 do?
 - What is the preferred configuration to test? Debug or Release?
 - Should I do some configuration on the dashboard? I have not found anything 
 in particular, except for claiming sites.
 - What architectures should be tested?
 
 Thanks,
 Raffi Enficiaud
 
 
 -- 
 
 Powered by www.kitware.com
 
 Please keep messages on-topic and check the CMake FAQ at: 
 http://www.cmake.org/Wiki/CMake_FAQ
 
 Kitware offers various services to support the CMake community. For more 
 information on each offering, please visit:
 
 CMake Support: http://cmake.org/cmake/help/support.html
 CMake Consulting: http://cmake.org/cmake/help/consulting.html
 CMake Training Courses: http://cmake.org/cmake/help/training.html
 
 Visit other Kitware open-source projects at 
 http://www.kitware.com/opensource/opensource.html
 
 Follow this link to subscribe/unsubscribe:
 http://public.kitware.com/mailman/listinfo/cmake-developers

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Introduction and volunteering for the Matlab package

[Raffi Enficiaud]

 On 13 Feb 2015, at 14:58, Brad King brad.k...@kitware.com wrote:
 
 On 02/13/2015 05:10 AM, Raffi Enficiaud wrote:
 3 build agents (lts14.04, osx10.9 and win7x64) are now running the nightly 
 with the CMake_TEST_FindMatlab set to ON.
 The site name is bambooagent.raffienficiaud @ 
 https://open.cdash.org/viewSite.php?siteid=11851project=1currenttime=1423789200
 
 Those look great!
 
 The one test failure on Windows may be because the total path length
 gets too deep and exceeds some internal MS tool limits of 260 characters.
 Please move the build to somewhere with a shorter path.  Usually I keep
 mine under 55 characters or so to the top of the build tree.

Args! I'll try to reconfigure the agent temporary build path then, but not 
before next week I am afraid. 

 
 In the two that use the Unix Makefiles generator you can also add
 
 set(CTEST_BUILD_FLAGS -j4) # parallel build level
 
 In all three dashboard scripts you could add:
 
 set(CTEST_TEST_ARGS PARALLEL_LEVEL 4)
 
 to get tests to run in parallel.  Of course you can set the levels
 based on the available hardware on each machine.

I'll do that!
Looks that things are on good tracks then,

Thanks for driving this,
Raffi Enficiaud
-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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] Introduction and volunteering for the Matlab package

[Raffi Enficiaud]

Hi,

My comments below:

 On 13 Feb 2015, at 15:33, Brad King brad.k...@kitware.com wrote:
 
 On 02/12/2015 11:19 AM, Raffi Enficiaud wrote:
 Please find attached the reworked patch
 
 Great, thanks.  Now that we have the nightly testing worked out I've
 committed this with minor tweaks as a draft of the change for testing:
 
 FindMatlab: Rewrite module and provide a usage API
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1c7710e9
 
 I have a few more comments to be addressed before merge to 'master'.
 You can base further patches on the above-linked commit.
 
 * Why is Matlab_VERSION_STRING cached?  Shouldn't it be computed
  every time from the matlab that was found?

In case the version is not found with an obvious method (on OSX 
/Applications/MATLABVersion, on Win32, the version also is given by the 
registry key), we have to find the version of matlab by running matlab itself. 
I am caching the version once I have it to prevent any further execution of 
matlab for retrieving this information. Launching Matlab is kind of heavy, 
involving also network connection sometimes (due to floating license).

 
 * No find modules ever REALPATH the found values in case the user
  has a reason to keep the symlinks.  Why do we need to resolve
  symlinks in Matlab_MAIN_PROGRAM?

In case a symlink of the binary called matlab exists in /usr/local/bin for 
instance, I need to retrieve the path of the libraries mex, mx etc, that are 
relative to the real installation path of matlab. This is what is happening in 
my institute, the installation being made on a netshare by IT ppl, that can 
switch the version in demand. When matlab is launched from a symlink, it is 
executed in its installation path anyway (the matlab program is a stub to 
another script), so I need also this piece of information.

 
 * Several if() calls are using explicit ${VAR} variable dereferences.
  Those should be converted to just if(VAR ...) to allow if() to
  implicitly dereference them and avoid surprises when their value
  happens to name another variable.

Ok will do.

 
 * I will remove the conditions on CMAKE_VERSION in the final upstream
  version because we know it always runs with the current CMake
  version.  You'll have to maintain a small patch on your external
  copy of the module for use with older CMake versions.

No problem, hope the informations above are clear enough and justify the 
choices made.

Thanks,
Raffi Enficiaud

-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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] Introduction and volunteering for the Matlab package

[Raffi Enficiaud]

Thanks for your feedback, I will address your comments this week-end.

Regards,
Raffi Enficiaud

 On 13 Feb 2015, at 16:36, Brad King brad.k...@kitware.com wrote:
 
 On 02/13/2015 09:43 AM, Raffi Enficiaud wrote:
 * Why is Matlab_VERSION_STRING cached?  Shouldn't it be computed
 every time from the matlab that was found?
 
 In case the version is not found with an obvious method
 (on OSX /Applications/MATLABVersion, on Win32, the version also is
 given by the registry key), we have to find the version of matlab
 by running matlab itself. I am caching the version once I have it
 to prevent any further execution of matlab for retrieving this
 information.
 
 Okay.  Currently the value is user-facing, but it shouldn't ever be
 edited manually, right?  Instead the detected version could be cached
 in an INTERNAL cache entry.  Also there should be a second internal
 entry that records which matlab program was executed to compute the
 version.  If the latter does not match then the version should be
 re-computed.
 
 In case a symlink of the binary called matlab exists in /usr/local/bin
 for instance, I need to retrieve the path of the libraries mex, mx etc,
 that are relative to the real installation path of matlab.
 
 In that case I think you should look for those pieces relative to
 the original executable location first, and if not found then
 resolve symlinks into a temporary variable name and then use that.
 The resolved path should not be made user-facing so that any user
 that sets Matlab_MAIN_PROGRAM explicitly will see that value
 persist.
 
 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] Introduction and volunteering for the Matlab package

[Raffi Enficiaud]

 On 12 Feb 2015, at 19:03, Brad King brad.k...@kitware.com wrote:
 
 
 The definition needs to be put in the cache of the CMake build itself,
 not passed to the ctest script.  To do that, add:
 
 set(dashboard_cache 
 CMake_TEST_FindMatlab:BOOL=ON
 )
 
 before including the common script.
 

Good, I am trying this now. 

- Is there any convention for CTEST_SITE? Would bambooagent.raffienficiaud do?
- What is the preferred configuration to test? Debug or Release?
- Should I do some configuration on the dashboard? I have not found anything in 
particular, except for claiming sites.
- What architectures should be tested?

Thanks,
Raffi Enficiaud


-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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