Hi Istvan, I tried the mkpackage.py and that worked fine, as did makespec.sh. Trying to build the RPM though, I got the following: [steven@localhost csound5]$ rpmbuild -bb csound.spec Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.81502 + umask 022 + cd /usr/src/redhat/BUILD + LANG=C + export LANG + unset DISPLAY + exit 0 Executing(%build): /bin/sh -e /var/tmp/rpm-tmp.81502 + umask 022 + cd /usr/src/redhat/BUILD + LANG=C + export LANG + unset DISPLAY + cd /home/steven/workspace/__package /var/tmp/rpm-tmp.81502: line 26: cd: /home/steven/workspace/__package: No such file or directory error: Bad exit status from /var/tmp/rpm-tmp.81502 (%build) RPM build errors: Bad exit status from /var/tmp/rpm-tmp.81502 (%build) I'm not sure what to do for __package. Besides that, everything seems to have gotten built just fine. One thought, I think I'd prefer to have things installed into /usr/local/lib/csound (lowercase) rather than .../Csound. It seems better to me to have: #include than #include But that's probably due to me being used to java conventions of package names being lower case. Some other thoughts: rather than having to build, move, erase, build, etc. for the 32 and 64 bit versions, it might be nicer if we can build the object files into different target directories in SConstruct. That would give a few advantages: -as we develop, we can take advantage of the dependency tracking of SConstruct and only rebuild what's necessary -we can easily build both 32 and 64 bit versions on a regular basis and perhaps that would allow more opportunities to test between the two -cleaner directories when building I recently went through a change of build tools (well, augmented really) with blue and had to reorder my directory structure to adhere to a convention set by the build tool. It ultimately has proven much more organized and easier to deal with for it. So in addition to the /src directory we have now, we could add a /target directory where all build artifacts are output to, which would include object files (two different roots for 32 and 64), and generated binaries, organized as you have them in your mkpackage.py file. After that, a clean would be as simple as "rm -rf target". Well, just some thoughts. Let me know what to do about the __package and I'll give it another go tomorrow. if it works out, I'll push an RPM out for other Fedora Core 4 users to try. steven On 11/2/05, Steven Yi wrote: > Hi Istvan, > > Apologies, I've had it down to try this out the past couple of nights > but things are very busy here personally. I'll give it a go tonight > (San Francisco Time). > > From what I saw initially just looking at the code, I didn't see the > files grabbing values from SConstruct. It'd be nice to hook them in > as a target, but I guess that should come in later anyways. > > BTW: I'm using Fedora Core 4 at home, and if you're using SuSE, that > should cover a lot of ground for RPM based distros. > > steven > > On 11/2/05, Istvan Varga wrote: > > Any comments ? > > > > Istvan Varga wrote: > > > > > I have committed the following files that can be used to create an > > > RPM distribution of Csound 5 on Linux: > > > > > > csound5/installer/linux/csound.spec.in > > > csound5/installer/linux/makespec.sh > > > csound5/installer/linux/mkpackage.py > > > > > > Building the package consists of these steps (for a non-RPM > > > distribution, only steps 1 to 4 are relevant): > > > > > > 1. enter the csound5 source directory > > > 2. edit ./installer/linux/mkpackage.py to change settings > > > 3. run ./installer/linux/mkpackage.py to compile Csound (this will > > > take quite a while, as multiple different configurations are > > > built). Once the build is complete, the directory ../__csound5 > > > will contain the files to be packaged. > > > 4. copy any required shared libraries that should be distributed with > > > the package (e.g. libportaudio.so or libportmidi.so) to > > > ../__csound5/usr/local/lib/Csound/lib > > > 5. edit ./installer/linux/csound.spec.in to set RPM header > > > information (do not change the last line) > > > 6. run ./installer/linux/makespec.sh to create the actual spec file > > > for the new package > > > 7. build the RPM file; this may depend on the distribution, the > > > one I use requires running 'rpmbuild -bb csound.spec' and the > > > package is written to /usr/src/packages/RPMS/i586 > > > > > > Note that these scripts are experimental, and will probably need > > > some changes; any feedback and suggestions are welcome. Currently, > > > the distribution includes Csound executables, plugins, utilities, > > > API library (both static and shared), header files, csoundapi~ for > > > PD, Python interface, string databases, and some documentation files. > > > Most of the binaries are included with both single and double > > > precision, with the exception of the PD object (always 32 bit) and > > > the Python module (always 64 bit). An example file list: > > > > > > ... > > > > > > ------------------------------------------------------- > > SF.Net email is sponsored by: > > Tame your development challenges with Apache's Geronimo App Server. Download > > it for free - -and be entered to win a 42" plasma tv or your very own > > Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php > > _______________________________________________ > > Csound-devel mailing list > > Csound-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/csound-devel > > > ------------------------------------------------------- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php _______________________________________________ Csound-devel mailing list Csound-devel@lists.sourceforge.net