|
Notes |
|
|
(0025576)
|
|
Martin Konrad
|
|
2011-02-24 12:43
|
|
|
I just uploaded a simple test case derived from the ComponentExample and the one used in 0007645. Is there a way to help? |
|
|
|
(0025577)
|
|
Eric NOULARD
|
|
2011-02-24 13:06
|
|
Yes there is,
The next step is to dive into the source
Source/CPack/cmCPackDebGenerator.cxx
and get inspiration from either:
Source/CPack/cmCPackRPMGenerator.cxx
or
Source/CPack/cmCPackArchiveGenerator.cxx
and provide a patch.
I would be happy to review it.
Thank you for the test case.
Currently there is a test case in
Tests/CPackComponentsForAll
which could be used for Deb as well. |
|
|
|
(0025604)
|
|
Martin Konrad
|
|
2011-03-01 04:23
|
|
|
I'm still confused about all that variables containing different toplevel directories. cmCPackDebGenerator::PackageFiles() iterates over a list called "files". This list seems to be filled by cmCPackGenerator::DoPackage(). But what directory needs to be changed to change the base directory for the files list to a component directory? What is the correct place to do that? There is no such thing in cmCPackRPMGenerator.cxx... |
|
|
|
(0025605)
|
|
Eric NOULARD
|
|
2011-03-01 05:05
|
|
Yes this is not that easy to understand from the code.
Now it is not that difficult either.
The things is when CPack (generic part) is asked to do an install
it does so in a so called "toplevel" directory
There is one toplevel for each generator, for example
if I used both RPM and ZIP generator to build a package I will
find in the build directory:
build/_CPack_Packages/Linux/ZIP/
build/_CPack_Packages/Linux/RPM/
which are the respective toplevel for each generator.
Now depending on whether if the specific generator asked for a
component install or not you will either find
- the whole hierarchy of files/dirs just below the toplevel
inside "${CPACK_PACKAGE_NAME}" dir
- one directory per component inside the toplevel+${CPACK_PACKAGE_NAME}
and the list of files/dirs belonging to this component
inside the toplevel dir.
Those file hierarchy are created by "InstallProject()" call.
Afterwards DoPackage examine ALL the file just installed
below the toplevel and create the "files" list:
gl.FindFiles(findExpr)
and later on
// The files to be installed
files = gl.GetFiles();
the comment is somehow misleading, the files have been installed
(inside the toplevel) but now we have to package them (CPack work).
Currently Deb generator wasn't component aware so it assumes
that all to-be-package files are just below toplevel.
You'll have to teach Deb generator to seek inside component specific dirs.
If you want to see some var values used by RPM generator, try the following:
cd <tobuilddir>
1) cpack -D CPACK_RPM_PACKAGE_DEBUG=1 -G RPM
This wiil package your project with RPM and component handling disabled.
2) cpack -D CPACK_RPM_PACKAGE_DEBUG=1 -D CPACK_RPM_COMPONENT_INSTALL=1 -G RPM
Same thing with component enable. |
|
|
|
(0025675)
|
|
Martin Konrad
|
|
2011-03-06 14:42
|
|
Thanks for your help Eric. Please have a look at my patch ("add_component_support_to_CPackDeb.diff"). It adds basic component support but doesn't handle dependencies between component packages yet. Any comments are appreciated.
I activated the tests for the DEB and RPM generator because I think they should be run if someone issues "make test". |
|
|
|
(0025678)
|
|
Eric NOULARD
|
|
2011-03-06 17:45
|
|
Thank you Martin,
I'll review your patch very soon. |
|
|
|
(0025692)
|
|
Eric NOULARD
|
|
2011-03-08 08:55
|
|
Hi Martin,
Thank you very much for the patch.
Some remarks:
1) Please do not put "possibly unrelated" topics
into the same patch.
i.e. if the path concerns CPackDeb then do not
include modifications for CPackRPM in the same patch.
Modifications for CPackRPM are more than welcome too
but please put it in a separate patch.
Concerning CPackRPM testing, it has been activated on
stage branch "CPackRPM-enableCPackTests" and merged to next.
I hope it will be merged during today next-->master round.
2) When you add a variable to CPackDeb.cmake
a) check whether something similar exists
b) if not then add the documentation concerning
this new var in the header of CPackDeb.cmake
You did add
CPACK_DEB_PACKAGE_DEBUG
which looks as the same as existing
CPACK_DEBIAN_PACKAGE_DEBUG
3) You cannot add DEB generator test without
testing if we are running on Linux and
may be if dpkg tool is found.
(CPackDeb work without it but it's better
to test on Debian host)
4) As you may have seen on cmake-developers mailing
list the distinction between
"AllGroupsInOne" and "AllInOne" is somehow a mistake
(my mistake) and at most misleading.
http://public.kitware.com/pipermail/cmake-developers/2011-March/001297.html [^]
Otherwise the patch looks good.
I did attach an updated patch which contains fix for my remarks
(but the one concerning AllGroupsInOne vs AllInOne).
If you are ok, we can wait until tomorrow until the next-->master
round is over and then you may rebase your work on updated master.
Then you update the tracker with the new patch and I'll push
it to a stage branch and merge it to next after some testing.
Then you can go on with dependencies etc... using the stage branch.
Would this process be Ok for you? |
|
|
|
(0025693)
|
|
Eric NOULARD
|
|
2011-03-08 08:59
|
|
I forgot one last remark.
CMake git repo has pre-commit hook which
verifies that there is no trailing whitespace on any line.
A KWstyle dashboard emit warning if anyt lines is longer than 80 characters.
You can avoid most of those if you use local commit hooks:
http://www.cmake.org/Wiki/Git/Hooks#update [^] |
|
|
|
(0025701)
|
|
Martin Konrad
|
|
2011-03-09 07:52
|
|
|
Here is a new revision of the patch (0002-cpackdeb-local-commit-of-martin-work.diff). It's rebased on the updated master. |
|
|
|
(0025702)
|
|
Martin Konrad
|
|
2011-03-09 07:53
|
|
Hi Eric,
thanks for your remarks.
1) and 2) You're definitely right.
3) In my eyes these tests should pass without dpkg, too (I just verified that on OpenSUSE 11.2). Even without Linux. Keep in mind that the Deb generator does not call any third party tools (like rpmbuild) but only uses the tools included in CMake. That's why I think we could activate this for _all_ machines to make sure it works smoothly everywhere. |
|
|
|
(0025703)
|
|
Martin Konrad
|
|
2011-03-09 08:34
|
|
|
I opened a new issue for dependency support: 0011944 |
|
|
|
(0025752)
|
|
Eric NOULARD
|
|
2011-03-10 16:36
|
|
Hi Martin,
I agree for 3) but I doubt it could be useful to anyone to build a "proper deb"
on anything else than a Debian based host.
Note that if you enable CPACK_DEBIAN_PACKAGE_SHLIBDEPS
then you'll need dpkg-shlibdeps, which does the dependency checking
in the "debian way".
For now I'd rather not run the tests on non-Linux host in order
to be sure it's ok on a wide range of machine.
Then if the CMake dashboard did not turned red, we will see if we can
enable it on non-Linux host.
By the way I'd like (if you are ok)
to commit this using your name and signed-off by me,
for doing that I need a valid e-mail address for you.
Could you send me your e-mail?
Mine is: eric -DOT- noulard *AT* gmail -DOT- com |
|
|
|
(0025757)
|
|
Martin Konrad
|
2011-03-11 02:35
(edited on: 2011-03-11 02:36) |
|
Think of an deb containing documentation for a project that runs on a Windows server. Perhaps it makes sense to generate debs for that on a Windows machine.
But you're right: Let's run the test only on Linux machines for a start.
Here is my e-mail: konrad at ikp dot tu-darmstadt dot de
|
|
|
|
(0025758)
|
|
Eric NOULARD
|
|
2011-03-11 02:50
|
|
Merge topic 'CPackDeb-ComponentSupport' into next
bf7066c CPackDeb add Component Support to DEB generator fix 0011655 |
|
|
|
(0025887)
|
|
Eric NOULARD
|
|
2011-03-23 13:40
|
|
The evolution is in master now.
More work on dependencies will be handled separately. |
|
|
|
(0027344)
|
|
David Cole
|
|
2011-09-05 11:37
|
|
|
Closing resolved issues that have not been updated in more than 4 months. |
|
ComponentExampleStart_deb.tar.bz2 (1,032) 2011-02-24 12:41
add_componenent_support_to_CPackDeb.diff (21,878) 2011-03-06 14:37