[CMake] BundleUtilities naming and easing packaging

[Eric Noulard]

2010/8/20 David Cole <david.cole at kitware.com>:
> On Fri, Aug 20, 2010 at 7:37 AM, Mike McQuaid <mike at mikemcquaid.com> wrote:
>>
>> Hi,
>>
>> There's been some discussion on
>> http://public.kitware.com/Bug/view.php?id=11126 and I raised the issue about
>> the BundleUtilities port to Windows/Linux: the naming is so bad as to make
>> this (pretty cool) feature completely undiscoverable.

Agreed.
I'm a user of neither BundleUtilities nor GetPrerequisites but
the available documentation are too partial if not cryptic:

BundleUtilities:
"A collection of CMake utility functions useful for dealing with .app
       bundles on the Mac and bundle-like directories on any OS."

May be beginning with an improved doc for those existing
"probably cool" tools would be a good start.

>> I assumed, as I'd think others would, that this would be somehow related
>> to creating .app bundle clones on Linux or Windows, not fixing up the
>> dependencies and installing them. I'd argue that anything relating to the
>> latter really belongs in GetPrerequisites and should be named differently.

GetPrerequisite does not have such a good doc either:
"This script provides functions to list the .dll, .dylib or .so files
       that an executable or shared library file depends on.  (Its
       prerequisites.)"

and then what should we do with that.

All this looks like valuable tools but you cannot get a clear picture
of what they do until you read the content of the corresponding CMake file.

>> For backwards compatibility purposes, obviously the current naming will
>> still need to work but is it possible to get some of this functionality
>> documented and described in a better location?
> Sorry about that. The name was chosen when the functionality was Mac-only,
> then we extended it to cover Windows/Linux. What name would you suggest as
> "more discoverable" or "better"?

May be beginning by enhancing the doc in the header of

BundleUtilities.cmake
GetPrerequisites.cmake

would be a good start which would help us to find better names.

>> Secondly, I'd like to propose a function like "install_prerequisites"
>> which would create all the INSTALL(CODE) stuff for you and call the various
>> needed functions, just to make it easier for people to be able to use
>> bundleutilities/getprerequisites without having to fight with INSTALL(CODE
>> or SCRIPT) problems.
>
> Well, since it needs all the files to exist at analysis time, such a command
> would have to generate code that is run at install time. I'd be surprised if
> you could easily generalize this such that a client project would not have
> to customize it at all, but I could be wrong...
> I'm not a big fan of making all this stuff "too automatic" (which is a
> completely subjective judgment call, but still...) -- because I think it's a
> good thing that developers have to be aware of all the dependencies in their
> code.
> If we make this completely automatic, people will blame CMake when
> they inadvertently pull in some GPL-ed component that they don't really
> *want* to depend on. Pushing the work onto the end-developer has the nice
> side effect of placing the responsibility for such inclusions directly on
> the end-developer. (Which is where it belongs.)

I do totally agree with that, automatic tool sucks when it begans to do things
you wouldn't have done yourself if you were aware of it.
Note however that some packaging tool like rpm or dpkg-xxx already do
such "automatic" dependency analysis on their own in order to fill-in
inter-package dependencies.

I think, may be something that if switched ON that could just WARN
about missing
dependencies in installed things would be good.

This would help the developer to scratch his head in order to figure WHY
he would ever need this GPL-ed thing as a dependency.

May be something like a MODE option to  PULLIN or WARN or ERROR
would be good.

>> Thirdly, I often want to install prerequisites or other files into the
>> packages generated by CPack but not when using make install. It would be
>> good if INSTALL(CODE) or other functions could have an argument to do
>> basically this:
>>  IF( \${CMAKE_INSTALL_PREFIX} MATCHES .*/_CPack_Packages/.* )
>>      <<<Stuff passed to INSTALL(CODE) in here>>>
>>   ENDIF( \${CMAKE_INSTALL_PREFIX} MATCHES .*/_CPack_Packages/.* )
>
> Not a big fan of this one either. Personally, I think it's stupid even to
> have differences between the build tree and the install tree. Now, with
> this, you'd have differences between the "make install" tree and the
> packaged install tree...? Why do you do this? Just to save devs some time at
> "make install" time? Or is there some other valid technical reason that my
> foggy morning brain isn't thinking of...?

Agreed too.
It 'may' be useful to package things which are not installed if they
appear to be handled
at preinstall step of the package installer itself.
For example I may want to build an RPM that would install some dependencies
with the package during %pre step.

If you want to do that you may want a way to specify those
"uninstalled" thing to
be picked up by CPack and not handled with "make install".

May be you can already use the "CPACK_INSTALL_DIRECTORIES" for that,
if FixUpDependencies (or any other appropriate name) create a directory which
contains the needed deps and you tell CPack using "CPACK_INSTALL_DIRECTORIES".

Then CPack should (not tested yet)  pick-up all you want even if
make install does its usual job.

>> I'm happy to help or develop these features, if they'd be accepted. It was
>> suggested that both would require Kitware buy-in before I should start
>> working on them.
>
> Thanks for opening these discussions, by the way. Good to know people are
> using this stuff even though they have to work through stuff to get to the
> end result.


-- 
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org