[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: