hi, i''m not convinced by current specific cdbs files (cmake.mk, kde.mk and utils.mk) used for kde4. Using single cmake.mk submitted on #377524 (used by every kde-extras packages) and a rules file (around 10 lines and attached), i have builded kdelibs/kdepimlibs/kdebase without problems. i found a "10 lines" rules more readable and easy to fix versus a bunch of files touching every KDE4 packages. so i would like to have some feedbacks on this point, pros/cons, point of view, whatever... cheers, Fathi -------------- next part -------------- #!/usr/bin/make -f #include debian/cdbs/kde.mk include debian/cdbs/cmake.mk include /usr/share/cdbs/1/rules/debhelper.mk include /usr/share/cdbs/1/rules/patchsys-quilt.mk include /usr/share/cdbs/1/rules/utils.mk DEB_COMPRESS_EXCLUDE = .dcl .docbook -license .tag .sty .el DEB_CMAKE_EXTRA_FLAGS = -DCMAKE_SKIP_RPATH=true \ -DCONFIG_INSTALL_DIR=/etc/kde4 \ -DDATA_INSTALL_DIR=/usr/share/kde4/apps \ -DHTML_INSTALL_DIR=/usr/share/doc/kde4/HTML \ -DKCFG_INSTALL_DIR=/usr/share/kde4/config.kcfg \ -DLIB_INSTALL_DIR=/usr/lib \ -DSYSCONF_INSTALL_DIR=/etc #DEB_CMAKE_PREFIX = /usr/lib/kde4 DEB_DH_INSTALL_ARGS = --sourcedir=debian/tmp #DEB_DH_SHLIBDEPS_ARGS = -l/usr/lib/kde4/lib/ #DEB_MAKE_ENVVARS += XDG_CONFIG_DIRS=/etc/xdg XDG_DATA_DIRS=/usr/share #DEB_STRIP_EXCLUDE = so
Fathi Boudra wrote:> i''m not convinced by current specific cdbs files (cmake.mk, kde.mk > and utils.mk) used for kde4.I think the process ought to be that we first get the KDE 4 packages into usable form and then figure out how to factor the necessary CDBS rules into pieces that are most useful to everybody.> i found a "10 lines" rules more readable and easy to fix versus a > bunch of files touching every KDE4 packages.I''m not sure what you are getting at, but I find a one-line rules file better than a 10 line one. But I''m pretty sure that by the time the KDE 4 packages are in their final shape, it will all look quite a bit more complex anyway, so it''s premature to fine-tune these things now.
> I think the process ought to be that we first get the KDE 4 packages > into usable form and then figure out how to factor the necessary CDBS > rules into pieces that are most useful to everybody.KDE4 packages are into usable form, what we miss: * copyright files, which is awfull and is a time killer. * upgrade path * kdelibs kde3/kde4 co-installable * not uploaded anywhere but it''s probably because we want something ready to use for experimental (at least, this is my POV).> I''m not sure what you are getting at, but I find a one-line rules file > better than a 10 line one.a one-line calling 3 others files which are not a one-line rules themselve. it hides other files and make dig into other files to find what we want (it reminds me cdbs nature ...), when i found a single file more readable especially a ten-line.> But I''m pretty sure that by the time the KDE 4 packages are in their final > shape, it will all look quite a bit more complex anyway, so it''s premature > to fine-tune these things now.i don''t think it''s premature. i submitted the cmake.mk one year ago, and play with kde4 since around 4 months. Sincerely, i don''t think there will be more fine-tuning compared what we have now: something easy to use and understandable by everybody. And i doubt there will be many improvement now. cheers, Fathi
On Saturday 04 August 2007, Fathi Boudra wrote:> hi, > > i''m not convinced by current specific cdbs files (cmake.mk, kde.mk and > utils.mk) used for kde4.Hi! I don''t know if you have forgotten past discussions or just chosen to ignore them. cmake.mk: Based on the one submitted by Fathi. The kde-specific -DFOO needs as mentioned several times earlier to be moved to the debian/kde.mk file. The only difference is IIRC that I have removed this nice piece of nothing: ifeq (,$(findstring noopt,$(DEB_BUILD_OPTIONS))) # well, -O0 endif ifneq (,$(findstring nostrip,$(DEB_BUILD_OPTIONS))) # semi-debug else # final endif ifneq (,$(findstring debug,$(DEB_BUILD_OPTIONS))) # debug endif and added the kde specific as mentioned. The todolist for this is to move the kde4 specific -DFOO to kde.mk. kde.mk: kde.mk is the successor of the debian/debian-qt-kde.mk file we currently have. It is used for stuff that should be in common for packages. The cmake -DFOO we have in cmake.mk should be moved to here where they belong. kde.mk also contains snippets to decide where to use enable-final, snippets to build man pages and to install docs. utils.mk: it is utils.mk from cdbs with the patch from 423394 added. The plan is to go back to the cdbs utils.mk when this bug is resolved. We need a way to add files that shouldn''t show up in the output from utils.mk The move of the -DFOO from cmake.mk to kde.mk is something that we need to do, but I don''t see it that important to do yet. I want them to be in a common file so that we have the possibilities to change and add stuff in _one_ place instead of all the many rules files in all packages> Using single cmake.mk submitted on #377524 (used by every kde-extras > packages) and a rules file (around 10 lines and attached), i have builded > kdelibs/kdepimlibs/kdebase without problems.As written, the plan is to move to a cdbs provided cmake.mk file. Currently it doesn''t differ much and the plan is to make it differ even less with moving the kde4 specific -DFOO elsewhere.> i found a "10 lines" rules more readable and easy to fix versus a bunch of > files touching every KDE4 packages.It depends on the kind of changes you need to make. When needing to change or add a -DFOO to all packages, having it in all rules files is a great pain in the arse. This is why we in kde3 packages also have a shared file for such stuff.> so i would like to have some feedbacks on this point, pros/cons, point of > view, whatever...Full NACK from here. /Sune -- How can I cancel the periferic? You need to explore the SIMM. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://lists.alioth.debian.org/pipermail/pkg-kde-talk/attachments/20070805/af345e7a/attachment.pgp
> I don''t know if you have forgotten past discussions or just chosen to > ignore them.if you talk about kde4 thread started on 27/04/2007, i hadn''t enough time to check the discussion and take it now. I don''t ignore anything or drop your work, i just ask a question and give my point of view.> cmake.mk: > Based on the one submitted by Fathi. The kde-specific -DFOO needs as > mentioned several times earlier to be moved to the debian/kde.mk file.i didn''t find anything on that. Probably irc, but as already mentionned, irc is not the best to keep discussion tracking.> The only difference is IIRC that I have removed this nice piece of nothing: > ifeq (,$(findstring noopt,$(DEB_BUILD_OPTIONS))) > # well, -O0 > endif > > ifneq (,$(findstring nostrip,$(DEB_BUILD_OPTIONS))) > # semi-debug > else > # final > endif > > ifneq (,$(findstring debug,$(DEB_BUILD_OPTIONS))) > # debug > endif > > and added the kde specific as mentioned. > > The todolist for this is to move the kde4 specific -DFOO to kde.mk.TODO list not available. it could be nice that peter after one year ... do something for this point. i would like to avoid to add specific stuff or diverge something specific for kde. i would like to use a general purpose cmake.mk provided by cdbs package. And it can be easily the case.> kde.mk: > kde.mk is the successor of the debian/debian-qt-kde.mk file we currently > have. It is used for stuff that should be in common for packages. The cmake > -DFOO we have in cmake.mk should be moved to here where they belong. > kde.mk also contains snippets to decide where to use enable-final, snippets > to build man pages and to install docs.the improvement provided by kde.mk are minor: * we don''t build manpages. * install docs correspond to -DHTML_INSTALL_DIR=/usr/share/doc/kde4/HTML. * specific cmake parameters for kde correspond to 7 values.> utils.mk: > it is utils.mk from cdbs with the patch from 423394 added. The plan is to > go back to the cdbs utils.mk when this bug is resolved. We need a way to > add files that shouldn''t show up in the output from utils.mklike for cmake.mk, it could be nice that peter do something for this point. it will make utils.mk divergence useless, which is something i would like too.> The move of the -DFOO from cmake.mk to kde.mk is something that we need to > do, but I don''t see it that important to do yet. I want them to be in a > common file so that we have the possibilities to change and add stuff in > _one_ place instead of all the many rules files in all packagesi agree on this point, it could be nice to have a common place, but is it needed ? so my point is if cmake.mk and utils.mk divergence become useless (hi peter \o/), we will have only kde.mk which contains specific kde4 parameters. And kde.mk, now looks like the rules i use ..> It depends on the kind of changes you need to make. When needing to change > or add a -DFOO to all packages, having it in all rules files is a great > pain in the arse. This is why we in kde3 packages also have a shared file > for such stuff.today, there''s nothing specific for any KDE4 packages. The point i see is we need a single file for KDE4 (call it rules or kde.mk), and this file will contain only 7 parameters. Do we want: * share this signle file between every packages => kde.mk * do not share this file between every packages => rules and i think share a simple (10 lines) file between several packages, more problematic (e.g.: make sure the change you do works on every packages) than use a rules per package. It isn''t worth the effort. cheers, Fathi
> today, there''s nothing specific for any KDE4 packages. > > The point i see is we need a single file for KDE4 (call it rules or > kde.mk), and this file will contain only 7 parameters. > > Do we want: > * share this signle file between every packages => kde.mk > * do not share this file between every packages => rules > > and i think share a simple (10 lines) file between several packages, more > problematic (e.g.: make sure the change you do works on every packages) > than use a rules per package. It isn''t worth the effort.it seems sharing a single file (kde.mk) between every packages is the way to go. At least, something i''ll agree on. TODO: * put cmake.mk in cdbs package (#377524) * update utils.mk in cdbs package (#423394) * merge kde4 specific stuff in kde.mk @peter: you are involved in the 2 related bug reports, could you do something on this ? cheers, Fathi
> it seems sharing a single file (kde.mk) between every packages is the way > to go. At least, something i''ll agree on. > > TODO: > * put cmake.mk in cdbs package (#377524) > * update utils.mk in cdbs package (#423394) > * merge kde4 specific stuff in kde.mkmerge kde4 specific stuff in from cmake.mk to kde.mk done.> @peter: you are involved in the 2 related bug reports, could you do > something on this ?when both bug will be resolved, we will be able to use cmake.mk and utils.mk provided by cdbs package and not our own version. kde.mk will be the only single file shared by every kde4 packages. not the ten-line file easily readable i have in mind but at least a common place and a single file. cheers, Fathi
Am Sonntag, 5. August 2007 11:28 schrieb Sune Vuorela:> kde.mk: > kde.mk is the successor of the debian/debian-qt-kde.mk file we currently > have. It is used for stuff that should be in common for packages. The cmake > -DFOO we have in cmake.mk should be moved to here where they belong. > kde.mk also contains snippets to decide where to use enable-final, snippets > to build man pages and to install docs.For the KDE 3 packages, there used to be a distinction between kde.mk for general KDE packages and debian-qt-kde.mk for packages maintained by the Qt/KDE team. Are you planning to keep that distinction?
[Don''t know if Peter is subscribed - cc''ing to be sure] On Monday 06 August 2007, Peter Eisentraut wrote:> For the KDE 3 packages, there used to be a distinction between kde.mk for > general KDE packages and debian-qt-kde.mk for packages maintained by the > Qt/KDE team. Are you planning to keep that distinction?The plan is to keep that distinction so far, yes. I have been sloppy with naming the kde.mk file, so please disregard the name of that file. Maybe some of the content could be moved to a generic kde4.mk file with the cmake default args, but let us look at how non-kde.org kde applications start to look before looking further in this direction. /Sune -- How to install a level-88 connector from Windows 95? From the preferences inside Photoshop you have to configure the button for deleting the TCP space bar. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://lists.alioth.debian.org/pipermail/pkg-kde-talk/attachments/20070807/c2bb5b15/attachment.pgp