Bug#678100: ITP: salome-{kernel,gui,med,geom,paravis,..} -- integration platform for numerical simulation
On 19/06/12 10:00, Julien Cristau wrote:
> On Tue, Jun 19, 2012 at 09:40:32 +0100, Dmitrijs Ledkovs wrote:
>
>> Good luck! It's a beast =)
>>
> Thanks :)
>
>> Did you see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=657433 ?
>>
> Yep. I'll start with a smaller set of modules, and get things in
> experimental at first to get a feel for the pain involved.
>
One thing I can recommend is using cdbs, due to native flavours support
Using:
DEB_MAKE_FLAVORS = pkg1 pkg2 pkg3
DEB_BUILDDIR = build
It will manage the machinery of running configure, build, test, install
for each of the flavours, conveniently installing each build under
debian/tmp/$flavors/ and using out of the tree builds (if you prefer)
(there are many more variables available)
Then you can do tricks like:
DEB_CONFIGURE_FLAGS_pkg1 = --enable-foo, --disable-bar
Or provide additional environment variables
debian/stamp-autotools/pkg1:: DEB_CONFIGURE_SCRIPT_ENV=PYTHON=python3
... and set dependencies between various packages using stable stamp names
Furthermore, if you use $(filter $(DEB_PACKAGES), pkg1 pkg2 pkg3), then
only those packages that are specified in debian/control will be build.
Win, cause this now means that you can work on packaging the next
component without affecting stable build... or choose to build more in
experimental and less components in unstable to gradually package more
and more of it.
I hope you will consider this, as this should save you from inventing
again the whole stamp/targets management and provide you with many
dynamic targets to do custom things per each debian package, flavour,
component, etc...
I think you will find it exceptionally useful to remove some stamp files
to rerun just one step of the build, instead of doing a massive
./debian/rules clean while developing as well.
Another thing to take into account is that ./debian/package.install and
similar dh_* helper files can now be executable & do variable replacements.
If that is not enough, and you want dh_install with rename support,
please look into dh-exec, cause it supports this:
usr/bin/foo => usr/bin/salome-foo
Using state of the art tools, I hope it will save you time and let you
concentrate on figuring out correct build flags, environment variables,
where to install what, and writing patches. Feel free to delegate
packaging questions & manual laborious tasks, by aggressively using help
tag in the bts. This package needs synergy! And there are a lot of
people in debian-science & debian-med who I think would be interested in
salome.
I have now a powerful machine to potentially build salome in reasonable
amount of time, but unfortunately I don't have much spare time to throw
myself into salome packaging.
All the best.
--
Regards,
Dmitrijs.
Reply to:
- References:
- Bug#678100: ITP: salome-{kernel,gui,med,geom,paravis,..} -- integration platform for numerical simulation
- From: Julien Cristau <julien.cristau@logilab.fr>
- Bug#678100: ITP: salome-{kernel,gui,med,geom,paravis,..} -- integration platform for numerical simulation
- From: Dmitrijs Ledkovs <xnox@debian.org>
- Bug#678100: ITP: salome-{kernel,gui,med,geom,paravis,..} -- integration platform for numerical simulation
- From: Julien Cristau <julien.cristau@logilab.fr>
- Prev by Date:
Bug#678338: ITP: konoha -- interpreter of statically-typed scripting language Konoha
- Next by Date:
Processed: ITA: freeglut -- OpenGL Utility Toolkit
- Previous by thread:
Bug#678100: ITP: salome-{kernel,gui,med,geom,paravis,..} -- integration platform for numerical simulation
- Next by thread:
Bug#678100: ITP: salome-{kernel,gui,med,geom,paravis,..} -- integration platform for numerical simulation
- Index(es):