[CMake] BundleUtilities naming and easing packaging

[David Cole]

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.


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



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



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



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


HTH,
David




>
> Thanks!
> --
> Cheers,
> Mike McQuaid
> http://mikemcquaid.com
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.cmake.org/mailman/listinfo/cmake
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20100820/23775280/attachment-0001.htm>