Re: [Sc-devel] [PROPOSE] adding automatic debian package building to SConscript

On Jan 27, 2008 9:52 PM, Dan Stowell <danstowell@xxxxxxxxx> wrote:

Hi k,

This is sounding good! Thanks for the effort

2008/1/27, krgn <k.gebbert@xxxxxxxxx>:

> Hello again,
>
> I have invested a bit more time into learning how to build packages on
> debian, especially using the pbuilder environment as mentioned in the mails
> before. There was a lot to learn, and there still is, but from what I can
> see from other packages, there seems to be no real problem in using scons
> (other than having to do more work than with other software). In particular,
> I have had a look into how Ardour is being built, which works very well.
> Adapting its system to SuperCollider already let me build a working .deb, of
> course with a few minor problems, ;) like the archive being empty, due to me
> leaving some files unconfigured. That shouldn't prove very difficult to fix
> though. I would be really happy if we could work on a solution that satifies
> all requirements, but I think that this implies that we agree on some code
> to co-author, particularly whether we use cdbs (which I find to be *very*
> well suited) or a different method.
>
> While doing the (from ardour adapted) build of a supercollider-3.1.1.deb I
> came across a couple of problems, which I think could be relevant in the
> scons bug described below. Basically, it required changing sc's SConstruct
> to _not_ delete some files (.sconf-dblite or so..) and adding the deletion
> for cleanup to the rules files (so the order it gets executed is right, and
> dpkg-source doesn't bail out). Was that the sort of problem Jan encountered
> with his scripts?
>
> I definitely agree that, given we have such a mechanism (which undoubtedly
> many people including myself would find useful) it should produce packages
> that in theory could be distributed through distributions. That throws up
> some questions for me, particularly how we structure the package(s), i.e. do
> we want different ones for each component [supercollider-server, -dev, -doc,
> -el, -sced, -scvim] or just a single package? In the light of the problems
> with scel/sced co-existence, would making seperate packages more sense, or
> is the goal to fix those issues within SuperCollider (i.e. through an
> adapter?) so that we could maybe assume a safe standard ide on linux (which
> one?).

I would vote for separate components, just like you specify:
[supercollider-server, -dev, -doc, -el, -sced, -scvim] plus -lang of
course. For example, there are definitely situations where I would
want to install just the server and nothing else; and situations where
I'd want server and lang, but no editor environments.

Best
Dan

> Would be cool to get some opinions on this, so we can maybe agree and work
> on something to make this work properly.
>
> Greetings,
>
>
> k
>
> > Hi,
>
> >
> > >
> > >> this seems useful.
> > >> Any objection to adding these?
> > >
> > > Could you attach the two other files as well?
> > >
> > > We already have a working debian package- integrating them with the
> > > main
> > > SConstruct-File shouldn't be hard, but is in principle uneccessary.
> > > For Example, mplayer comes also with a debian/ which can be used
> > > simply
> > > by typing 'debian/rules binary'.
> > >
> > > More important: This will not fix an SConstruct-Bug which prevents us
> > > from building it at the moment :(. I will distribute our updated
> > > debian/ if it builds successfully. I think getting an updated Version
> > > of SC3 into Debian/Ubuntu should have first priority- everything else
> > > will be a byproduct of this. IMO, adding a hacked Debian support to
> > > the scons-files instead is not the way to go. As already pointed out,
> > > there is only little work done creating a complete 'control' file.
> > > Also,
> > > a package build like this will AFAIK never be accepted into Debian/
> > > Ubuntu.
> > >
> > > Details of SConstruct-Bug I mentioned:
> > > If you try to build the package in an environment that only fetches
> > > the
> > > build-requirements (usually via 'apt-get build-deps') the SConstruct
> > > file will
> > > abort, because it checks for the required libraries any time it runs
> > > and
> > > exits if it doesn't find it:
> > >
> > >> >From the Source [1]:
> > > 349 # sndfile
> > > 350 success, libraries['sndfile'] = conf.CheckPKG('sndfile >=
> > > 1.0.16')
> > > 351 if not success: Exit(1)
> > > 352
> > > 353 # FFTW
> > > 354 success, libraries['fftwf'] = conf.CheckPKG('fftw3f')
> > > 355 if not success: Exit(1)
> > >
> > > If I recall correctly this also applies to the check for pkgconfig.
> > > You may ask: Why is this a problem? Well, it is good practice to
> > > build Debian
> > > packages in
> > > such an environment, for example with pbuilder [2], because
> > > missing build-dependencies will be noticed immediately. Also, you can
> > > build packages for any distribution for it. The software extracts a
> > > base
> > > system tarball into a temporary directory, extracts the debian sources
> > > into it, chroots into it, runs a 'make clean' (this is where the
> > > current
> > > check breaks), installs the build dependencies, builds the package,
> > > copies
> > > the created debian packages and removes the temporary chroot.
> > >
> > > But getting this to work needs a fix of the above-described bug. Any
> > > help to fix it is much appreciated.
> > >
> > > 3c
> > >
> > > Grüße,
> > > Jan
> >
> > >
> > >
> > >
> >
> > _______________________________________________
> > Sc-devel mailing list
> > Sc-devel@xxxxxxxxxxxxxxx
> > http://lists.create.ucsb.edu/mailman/listinfo/sc-devel
> >
>
>
> _______________________________________________
> Sc-devel mailing list
> Sc-devel@xxxxxxxxxxxxxxx
> http://lists.create.ucsb.edu/mailman/listinfo/sc-devel
>
>

--
http://www.mcld.co.uk
_______________________________________________

Sc-devel mailing list
Sc-devel@xxxxxxxxxxxxxxx
http://lists.create.ucsb.edu/mailman/listinfo/sc-devel