[cmake-developers] CPack API redesign

Eric Noulard eric.noulard at gmail.com
Tue Aug 10 16:01:22 EDT 2010


Hi All,

After some discussion with Brad concerning the inclusion
of my patch proposal from component
(http://public.kitware.com/Bug/view.php?id=10736)

I decided to propose some CPack internal API redesign
that will ease the development of component support for
all CPack generators including  ArchiveGenerators, RPM and DEB.

The proposed changes may be pulled from there:
http://github.com/TheErk/CMake/tree/CPack-APIredesign

The main purpose of the changes is to let the specific generator decide
the name and number of the generated package(s).

The multi-arguments CompressFiles(...) API  has been renamed
to the no-arg PackageFiles().

The old arguments (packageName, toplevel, files) are now member
variables of cmCPackGenerator mother class.
Those arguments are "prepared" by the mother class before calling
PackageFiles() which may uses thoses and/or change their content.

The pullable changes includes the API update for **ALL** current CPack
generators
the changes have been tested on a Linux x64 box:

 1) with  ctest -R "CPack.*"
 2) by hand for several project (including CMake itself)
     for DEB   NSIS  RPM   STGZ  TBZ2  TGZ   TZ    ZIP

Cygwin (Source and Binary)
the various Mac OS generator (PackageMaker, OSXX11, Bundle)
have been updated too but

I did it **blindly** because I have to Mac nor Windows box at hand.

I would be glad if some of you may pull those changes and test them
on any platform and/or exotic use of CPack
(for example CPack without CMake)

The changes do not bring anything new but internal redesign,
i.e. ALL should work as before.

When/if this set of changes seems acceptable for all of you
I request a pull to next and then to master.

>From that point I will go on to:
 - port the old ArchiveGenerators patches to the new internal API
 - work on component support for RPM and DEB.

Thank you.

PS: I know that some of you did already take time to test my previous patchset
      but after discussion it seems more reasonable to first redesign the
      CPack internal API before merging such change.
      (and there was concurrent changes with libarchive:
http://public.kitware.com/Bug/view.php?id=11020)
      be sure I did appreciate your testing effort.

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



More information about the cmake-developers mailing list