On 7/30/10 6:35 AM, Eric Noulard wrote:
Hi All,
I'll try to launch a specific thread for this following what
Kishore said:
I would like to see full support for multiple components in cpack.
David answered:
Could you elaborate on "full support for multiple components in cpack" either
in another thread,
or in a feature request bug in the bug tracker?
With NSIS on Windows and PackageMaker on Mac, we already have what I would consider
"full support". Are you talking about
extending that to additional CPack generators or is there something missing
even in those generators in your opinion?
An explanation on CPack Component may be found here:
http://www.itk.org/Wiki/CMake:Component_Install_With_CPack
As David said currently the only 2 CPack generators which support Components are
- NSIS
- PackageMaker
I personally would like a wider support including RPM, DEB, TGZ (and
may be ZIP and other archive-like).
There is at least one bug/feature report/request for that for CPackRPM:
http://public.kitware.com/Bug/view.php?id=7645
From my point of view for the RPM/DEB/archive (TBZ2 TGZ TZ ZIP)
COMPONENT installer there is two "global" options:
A) Put all the components in a single archive with some hierarchical
structure inside
i.e. build a TGZ whose structure may be;
toplevel-name/component1/...
/component2/...
etc...
B) Build as many files as components.
toplevel-name-component1.tgz
toplevel-name-component2.tgz
toplevel-name-component3.tgz
The scheme A) is not quite usable for RPM or DEB
but it is ok for "pure" archive like TBZ2 , TGZ, TZ, ZIP.
My **personal** opinion is that for this kind of installers I'd rather
go for B).
The current problem with B) is that current CPack architecture does
not authorize it see:
http://public.kitware.com/Bug/view.php?id=10736
Like I said in another mail if we tackle the "multiple file problem" we should
be able to solve the "naming convention problem" too, see:
http://public.kitware.com/Bug/view.php?id=9900
So I would like those 2 bugs (9900, 10736)
solved, which would enable the may-be-easy creation
of full support for CPack COMPONENTs in any case (including bug 7645).
Please comment on those ideas or indicate whether if you agree with my
analysis or not.
Once we have some opinions ideas on this, I'll propose a new/updated
API for CPack generators
concerning this.
I personally would like option B - at the moment I basically work around
this by making an OPTION and then putting install commands inside if
statements. (Basically, not everybody using my work will want every
part of it, and I can anticipate easily the parts that might not be
needed - the common case of a runtime system/language that also provides
a c/c++ api and headers for more advanced usage.)
Ryan
--
Ryan Pavlik
Human-Computer Interaction Graduate Student
Virtual Reality Applications Center
Iowa State University
rpav...@iastate.edu
http://academic.cleardefinition.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
