[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sc-devel] [PROPOSE] adding automatic debian package building to SConscript
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?).
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
http://lists.create.ucsb.edu/mailman/listinfo/sc-devel