[PD] I created an ebuild for pd-0.40-p2

Hans-Christoph Steiner hans at eds.org
Fri Apr 20 02:06:55 CEST 2007


It seems that these ebuild files could use the existing build system  
quite easily.  The existing system isn't always pretty, but it  
works.  And ultimately we will both be better off if we join forces  
rather than have duplicate efforts.  I am definitely open to  
improving the existing system.  And I can help get you up to speed  
via email, IM, IRC, voice, whatever.

For example, in maxlib/maxlib-9999.ebuild, it could call the existing  
build system like this:

src_compile() {
	make -C /path/to/pure-data/externals maxlib
}

src_install() {
	make -C /path/to/pure-data/externals DESTDIR="${D}" maxlib_install
}

And that would be enough to build and install.  This is how it was  
done for PlanetCCRMA.  Then you could generate this same .ebuild file  
using a script for all of the libraries built by Pd-extended.  That  
also means that a given developer could manage just their own  
Makefile, and the changes will automatically be used in all the  
builds, including the gentoo.  Otherwise, you'll have to keep up with  
the changes that developers make to their own code.

Here is the current list of libraries that are built this way:  boids  
bsaylor creb cxc cyclone deprecated ekext ext13 flatspace flib  
freeverb ggee hardware hcs iem_ambi iem_bin_ambi iemlib jasch_lib  
loaders mapping markex maxlib mjlib motex mrpeach msd oscx pan pddp  
pdogg pmpd sigpack smlib toxy unauthorized vbap zexy pdcontainer  
adaptive iem_delay iem_roomsim iem_spec2 iem_tab flashserver iemgui  
iem_adaptfilt iemmatrix iem_matrix iemxmlrpc iem16 earplug hid pdp  
pidip hdspm_mixer

On Apr 19, 2007, at 2:53 PM, federico wrote:
> My advice is to leave the overlay on SVN, also because (hopefully) one
> day those ebuilds will go in the official gentoo repository, or at
> least in gentoo-sunrise (one of the biggest addon repos), so the task
> of syncing ebuilds will be totally transparent (it est: managed by
> emerge --sync).
>
> until that day, you can add two commands that sync pd-related ebuilds
> from our repository, just before the line that compiles everything
> (that will be: emerge media-sound/pd media-plugins/zexy
> media-plugins/maxlib ...) into your cron job:
>
> -----------[gentoo nightly build script]---------
> pushd /usr/local/overlays
> svn co https://svn.sourceforge.net/svnroot/pd-overlay/pd-overlay
> popd
> # emerging stuff, like:
> #   emerge pd maxlib zexy 2>&1 | tee emerge-pd.log
> -----------------------[end]---------------------
>
> so, whenever something breaks in the gentoo build farm, it could
> depend on two factors:
>
> 1) I (or someone of pd-overlay team) has made some mistake in the
> ebuild script. I will fix that (pls file bugs at
> https://sourceforge.net/tracker/? 
> atid=892936&group_id=180376&func=browse)
>
> 2) A developer changed something (tipically a Makefile) breaking the
> gentoo install someway (this can be fixed by both, just a matter of
> deciding *what* to fix, if the Makefile or the ebuild) or breaking the
> gentoo compile (this often should be solved upstream)
>
>> I don't use gentoo at all, so I'll leave that up to you.  Maybe a
>> good way to manage this is that you guys make releases of pd-overlay,
>> I check those releases into the pure-data CVS.  Then the nightly  
>> auto-
>> builds run using the stuff in pure-data CVS.
>
> I don't think repo-releases are needed.

Right now, one of the key reasons why the auto-build farm is limited  
to the pure-data CVS on SourceForge is because of security.   
Basically, anyone who has commit access to the pure-data CVS can run  
any script they want on all of the machines.  Therefore, I need to  
keep tabs on what scripts are being added to the CVS.  I also know  
who has commit access to the pure-data CVS.

Ideally, I wouldn't have to worry about security, but these machines  
are hosted by the university I work at.  If they get hacked, IT will  
tell me to remove them from the network.  Then we have no more auto- 
build farm.

> We try to put into SVN only working ebuilds (tested on our computers);
> the simplest ebuild that compiles and installs with:
>  ./configure && make && make install
> should be 100% fail-safe
>
> But the point is: actually 99% of our ebuilds have version -9999 (a
> convention to mean that their sources are pulled from Pd CVS) so they
> are more subject to break on CVS changes, especially when Makefile
> stuff like PREFIX and DESTDIR gets touched (!)
>
> Making releases/snapshots for *every* external would help a lot
> improving reliability; though this is not primary purpose of the
> project; would be better to rely that each commit on pd-cvs doesn't
> break anything :)
>
> Also: like other package management, we could mark ebuilds unstable,
> testing or stable, with simple use of keywords (please see the gentoo
> manual for more detail on this)

>
>
>> The key to making this work is having pd-overlay use the same
>> directory structure as the pure-data CVS.
>
> can you explain better what do you mean?
> pd-overlay has the structure of a gentoo ebuild tree. I don't believe
> it can be altered in some way

I mean that when the ebuild is looking for externals/Makefile, it  
knows it can find it at ../../external/Makefile, whether in pd- 
overlay or pure-data CVS. Make sense?  Other than that, it doesn't  
matter.  This could also be done like this:

PURE-DATA_ROOT=/path/to/pure-data
then the ebuild script would use $PURE-DATA_ROOT/externals/Makefile,  
and PURE-DATA_ROOT could be set for each location.

>> I've never installed gentoo.  Could you point me to a CD image to
>> install?  Also, once it's installed, will you install all of the
>> dependencies?  I'll give you shell access to do that.  Please
>> document this on a wiki page too.
>
> if you are going to install gentoo on x86 arch:
>
> * get the install ISO here:
>  http://bouncer.gentoo.org/?product=gentoo-2006.1-minimal&os=x86
> * refer to the x86 handbook for installing:
>  http://www.gentoo.org/doc/en/handbook/handbook-x86.xml
>
> the same applies for other archs, like ppc, ia64, amd64, ppc64,  
> hppa, alpha, ...
>
> dependencies are checked automatically, so emerge-ing pd would install
> also Xorg, alsa, tcl, tk, etc....
>
> anyway I can check your box for consistance :) just do the initial
> part of the install so that it can be bootable, then mail me ssh
> access, or let us meet on irc

sure, #dataflow?  I'll try to start this tomorrow, otherwise Mon or Wed.

.hc

>
> -- 
> Federico



------------------------------------------------------------------------ 
----

The arc of history bends towards justice.     - Dr. Martin Luther  
King, Jr.






More information about the Pd-list mailing list