David Merrill wrote:
Hello all,
hi. i am redirecting this to pd-dev, since i hope this mail will lead to some further dev-specific discussion and hopefully to some usable build system.
Has anyone else had a problem trying to compile an external from the CVS source? I just checked out the externals dir from CVS, and wanted to compile the latest [hid], so after reading the README in the hid directory, I typed:
make INCLUDE=/usr/lib/pd/src PDEXECUTABLE=/usr/bin/pd
..and got the following:
--paste--
[...]
--end paste--
Why would the build want a /sigpack, and /zexy directory? And am I missing a Makefile.buildlayout file?
to compile hid (and i guess, any of hans's externals) you need the entire pd-cvs (at the very least you need the "packages" module) downloaded from sourceforge. i agree that this is _very annoying_ at the least.
my solution to compile something as simple as [folder_list] was to NOT use hcs's build system at all (i really just wanted to have to download not more than 1MB to get this single object), but instead compile the object with:
gcc -g -O2 -I. -DPD -fPIC -export_dynamic -shared -o folder_list.o -c
folder_list.c
gcc -export_dynamic -shared -o folder_list.pd_linux folder_list.o -lm -lc
you might try something similar with hid, although things are a bit more complicated here.
that's basically the answer to your question, the rest is what i draw as a conclusion:
SO:
i see the need for a "grand unified build system" for things like pd-extended. but i am not totally sure, whether everything should be sacrificed to pd-extended. naturally, hans has the right to do anything with his code, including forcing anyone trying to build the sources from his part of the repository with any build system he likes. nevertheless, i would recommend a system that would make the best of the two worlds: be able to take advantage of the general pd-extended build system and (at the users option) be able to not have to use the pd-extended build system (probably at the cost of having to do some manual configuration if the maintainer doesn't want to maintain to configuration systems)
the simplest solution that comes to my mind is, that one of the 2 systems uses a differently named makefile. since pd-extended's build-system is more likely to be called from a parent makefile (because somebody wants to build the entire pd-extended build-system), i suggest to name this Makefile.extended (or Makefile.buildsystem) anybody wishing to build using the extended build system, would call "make -f Makefile.extended". other users would just do a "make".
a more sophisticated method would use a Makefile.extended and a Makefile.simple. the ordinary "Makefile" would first check for the existence of the extended build-system and if present, it would use Makefile.extended, else it would use Makefile.simple.
if test -e ../../packages/Makefile.buildlayout then # cool, we can use the extended build system make -f Makefile.extended else # simple fallback make -f Makefile.simple fi
what do you think?
mfg.adsr IOhannes
Hi all, agreed. Personally, I rarely use the extended distro since i only need a few externals or library, and i don't like to be dependent on a large and probably hard to maintain build system. I advocate simple Makefile files that are self-consistent and Makefile.extended or whatever for Hans' GUBS. greetings, Thomas
IOhannes m zmoelnig schrieb:
David Merrill wrote:
Hello all,
hi. i am redirecting this to pd-dev, since i hope this mail will lead to some further dev-specific discussion and hopefully to some usable build system.
Has anyone else had a problem trying to compile an external from the CVS source? I just checked out the externals dir from CVS, and wanted to compile the latest [hid], so after reading the README in the hid directory, I typed:
make INCLUDE=/usr/lib/pd/src PDEXECUTABLE=/usr/bin/pd
..and got the following:
--paste--
[...]
--end paste--
Why would the build want a /sigpack, and /zexy directory? And am I missing a Makefile.buildlayout file?
to compile hid (and i guess, any of hans's externals) you need the entire pd-cvs (at the very least you need the "packages" module) downloaded from sourceforge. i agree that this is _very annoying_ at the least.
my solution to compile something as simple as [folder_list] was to NOT use hcs's build system at all (i really just wanted to have to download not more than 1MB to get this single object), but instead compile the object with:
gcc -g -O2 -I. -DPD -fPIC -export_dynamic -shared -o folder_list.o
-c folder_list.c
gcc -export_dynamic -shared -o folder_list.pd_linux folder_list.o
-lm -lc
you might try something similar with hid, although things are a bit more complicated here.
that's basically the answer to your question, the rest is what i draw as a conclusion:
SO:
i see the need for a "grand unified build system" for things like pd-extended. but i am not totally sure, whether everything should be sacrificed to pd-extended. naturally, hans has the right to do anything with his code, including forcing anyone trying to build the sources from his part of the repository with any build system he likes. nevertheless, i would recommend a system that would make the best of the two worlds: be able to take advantage of the general pd-extended build system and (at the users option) be able to not have to use the pd-extended build system (probably at the cost of having to do some manual configuration if the maintainer doesn't want to maintain to configuration systems)
the simplest solution that comes to my mind is, that one of the 2 systems uses a differently named makefile. since pd-extended's build-system is more likely to be called from a parent makefile (because somebody wants to build the entire pd-extended build-system), i suggest to name this Makefile.extended (or Makefile.buildsystem) anybody wishing to build using the extended build system, would call "make -f Makefile.extended". other users would just do a "make".
a more sophisticated method would use a Makefile.extended and a Makefile.simple. the ordinary "Makefile" would first check for the existence of the extended build-system and if present, it would use Makefile.extended, else it would use Makefile.simple.
if test -e ../../packages/Makefile.buildlayout then # cool, we can use the extended build system make -f Makefile.extended else # simple fallback make -f Makefile.simple fi
what do you think?
mfg.adsr IOhannes
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Considering that its now building nightly automatically on numerous platforms, and I've largely single-handedly converted most of the libraries in CVS to build in libdir format, I don't think the Pd- extended build system has proven hard to maintain. I do sleep, and actually have a life outside of the Pd-extended build system... sometimes... ;)
In fact, its much better than anything that existed before. That is not to say there isn't a lot that could be improved. config.h!!
.hc
On Aug 9, 2006, at 6:37 AM, Thomas Grill wrote:
Hi all, agreed. Personally, I rarely use the extended distro since i only need a few externals or library, and i don't like to be dependent on a large and probably hard to maintain build system. I advocate simple Makefile files that are self-consistent and Makefile.extended or whatever for Hans' GUBS. greetings, Thomas
IOhannes m zmoelnig schrieb:
David Merrill wrote:
Hello all,
hi. i am redirecting this to pd-dev, since i hope this mail will lead to some further dev-specific discussion and hopefully to some usable build system.
Has anyone else had a problem trying to compile an external from the CVS source? I just checked out the externals dir from CVS, and wanted to compile the latest [hid], so after reading the README in the hid directory, I typed:
make INCLUDE=/usr/lib/pd/src PDEXECUTABLE=/usr/bin/pd
..and got the following:
--paste--
[...]
--end paste--
Why would the build want a /sigpack, and /zexy directory? And am I missing a Makefile.buildlayout file?
to compile hid (and i guess, any of hans's externals) you need the entire pd-cvs (at the very least you need the "packages" module) downloaded from sourceforge. i agree that this is _very annoying_ at the least.
my solution to compile something as simple as [folder_list] was to NOT use hcs's build system at all (i really just wanted to have to download not more than 1MB to get this single object), but instead compile the object with:
gcc -g -O2 -I. -DPD -fPIC -export_dynamic -shared -o
folder_list.o -c folder_list.c
gcc -export_dynamic -shared -o folder_list.pd_linux
folder_list.o -lm -lc
you might try something similar with hid, although things are a bit more complicated here.
that's basically the answer to your question, the rest is what i draw as a conclusion:
SO:
i see the need for a "grand unified build system" for things like pd-extended. but i am not totally sure, whether everything should be sacrificed to pd-extended. naturally, hans has the right to do anything with his code, including forcing anyone trying to build the sources from his part of the repository with any build system he likes. nevertheless, i would recommend a system that would make the best of the two worlds: be able to take advantage of the general pd- extended build system and (at the users option) be able to not have to use the pd-extended build system (probably at the cost of having to do some manual configuration if the maintainer doesn't want to maintain to configuration systems)
the simplest solution that comes to my mind is, that one of the 2 systems uses a differently named makefile. since pd-extended's build-system is more likely to be called from a parent makefile (because somebody wants to build the entire pd- extended build-system), i suggest to name this Makefile.extended (or Makefile.buildsystem) anybody wishing to build using the extended build system, would call "make -f Makefile.extended". other users would just do a "make".
a more sophisticated method would use a Makefile.extended and a Makefile.simple. the ordinary "Makefile" would first check for the existence of the extended build-system and if present, it would use Makefile.extended, else it would use Makefile.simple.
if test -e ../../packages/Makefile.buildlayout then # cool, we can use the extended build system make -f Makefile.extended else # simple fallback make -f Makefile.simple fi
what do you think?
mfg.adsr IOhannes
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
-- Thomas Grill http://grrrr.org
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
If you want to build a better build system, please go ahead and do it. Just don't break anything in the process since thousands of people rely on it. Please do not experiment on my code since trivial changes can cause problems which take hours to fix. I already experienced this with the addition of pd-devel to the Pd-extended build system. I had to spend hours debugging the changes in order to get Pd-extended building again. That is also very annoying at the least.
The simple changes that you propose seem simple on the face, but have the possibility to wreak major havoc. If you want to build another build system, then you should do what I did when building Pd- extended: I left everything in place without touching it and built the Pd-extended stuff alongside the existing build.
But yet again, it seems to me a massive waste of time to build Yet Another Build System. How about instead making the existing one better? For example, the Pd-extended build system would be much more flexible if there was a ./configure interface for it. I think we should extend pd/src/configure.in to create a config.h and have everything build against that.
.hc
On Aug 9, 2006, at 4:21 AM, IOhannes m zmoelnig wrote:
David Merrill wrote:
Hello all,
hi. i am redirecting this to pd-dev, since i hope this mail will lead to some further dev-specific discussion and hopefully to some usable build system.
Has anyone else had a problem trying to compile an external from the CVS source? I just checked out the externals dir from CVS, and wanted to compile the latest [hid], so after reading the README in the hid directory, I typed:
make INCLUDE=/usr/lib/pd/src PDEXECUTABLE=/usr/bin/pd
..and got the following: --paste--
[...]
--end paste-- Why would the build want a /sigpack, and /zexy directory? And am I missing a Makefile.buildlayout file?
to compile hid (and i guess, any of hans's externals) you need the entire pd-cvs (at the very least you need the "packages" module) downloaded from sourceforge. i agree that this is _very annoying_ at the least.
my solution to compile something as simple as [folder_list] was to NOT use hcs's build system at all (i really just wanted to have to download not more than 1MB to get this single object), but instead compile the object with:
gcc -g -O2 -I. -DPD -fPIC -export_dynamic -shared -o
folder_list.o -c folder_list.c
gcc -export_dynamic -shared -o folder_list.pd_linux folder_list.o
-lm -lc
you might try something similar with hid, although things are a bit more complicated here.
that's basically the answer to your question, the rest is what i draw as a conclusion:
SO:
i see the need for a "grand unified build system" for things like pd-extended. but i am not totally sure, whether everything should be sacrificed to pd-extended. naturally, hans has the right to do anything with his code, including forcing anyone trying to build the sources from his part of the repository with any build system he likes. nevertheless, i would recommend a system that would make the best of the two worlds: be able to take advantage of the general pd- extended build system and (at the users option) be able to not have to use the pd-extended build system (probably at the cost of having to do some manual configuration if the maintainer doesn't want to maintain to configuration systems)
the simplest solution that comes to my mind is, that one of the 2 systems uses a differently named makefile. since pd-extended's build-system is more likely to be called from a parent makefile (because somebody wants to build the entire pd- extended build-system), i suggest to name this Makefile.extended (or Makefile.buildsystem) anybody wishing to build using the extended build system, would call "make -f Makefile.extended". other users would just do a "make".
a more sophisticated method would use a Makefile.extended and a Makefile.simple. the ordinary "Makefile" would first check for the existence of the extended build-system and if present, it would use Makefile.extended, else it would use Makefile.simple.
if test -e ../../packages/Makefile.buildlayout then # cool, we can use the extended build system make -f Makefile.extended else # simple fallback make -f Makefile.simple fi
what do you think?
mfg.adsr IOhannes
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
But yet again, it seems to me a massive waste of time to build Yet Another Build System. How about instead making the existing one better?
I agree with that, and I see IOhannes' and Thomas' wish for being able to build smaller parts of the whole Pd-extended shebang as one possible enhancement to the big build system.
What I mean is: Maybe there is a way to make the makefiles in the various subdirectories also handle small builds? I don't really understand how it currently works, but for example a single external like hid.pd_linux has to be built anyways. So if I chdir to /externals/hcs/hid the makefile maybe could get an additional target so that I could call "make hid.pd_linux" there? I remember that it was once that way, but currently it doesn't work anymore.
I guess offering both approaches could be possible as well? I mean, even Debian manages to build thousands of packages decentralized and package them into one big distribution. ;)
Note that I'm a complete idiot when it comes to make and auto-whatever, I just understand enough to do educated guesses when copy-and-pasting, that's it.
Ciao
On 8/9/06, Frank Barknecht fbar@footils.org wrote:
What I mean is: Maybe there is a way to make the makefiles in the various subdirectories also handle small builds? I don't really understand how it currently works, but for example a single external like hid.pd_linux has to be built anyways. So if I chdir to /externals/hcs/hid the makefile maybe could get an additional target so that I could call "make hid.pd_linux" there? I remember that it was once that way, but currently it doesn't work anymore.
I agree that this would be a nice addition, so that a person doesn't have to download the entire source tree in order to compile a single external.. Making these smaller makefiles shouldn't break the rest of the existing functionality, correct?
-David M.
On Aug 9, 2006, at 4:57 PM, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
But yet again, it seems to me a massive waste of time to build Yet Another Build System. How about instead making the existing one better?
I agree with that, and I see IOhannes' and Thomas' wish for being able to build smaller parts of the whole Pd-extended shebang as one possible enhancement to the big build system.
What I mean is: Maybe there is a way to make the makefiles in the various subdirectories also handle small builds? I don't really understand how it currently works, but for example a single external like hid.pd_linux has to be built anyways. So if I chdir to /externals/hcs/hid the makefile maybe could get an additional target so that I could call "make hid.pd_linux" there? I remember that it was once that way, but currently it doesn't work anymore.
I guess offering both approaches could be possible as well? I mean, even Debian manages to build thousands of packages decentralized and package them into one big distribution. ;)
Note that I'm a complete idiot when it comes to make and auto-whatever, I just understand enough to do educated guesses when copy-and-pasting, that's it.
externals/hcs/hid/Makefile allows you do type things like:
make make clean make install
And it'll build [hid] and friends. That Makefile calls externals/ Makefile so that I only have to maintain one. That Makefile will also automatically set itself up if you stick into your CVS folder and there are targets of the same name in externals/Makefile. You can also see the same file in action here:
externals/deprecated/Makefile externals/hcs/Makefile externals/hcs/usbhid/Makefile externals/bsaylor/Makefile externals/corelibs/Makefile externals/sigpack/Makefile
and more... But yes, this still depends on having packages/ Makefile.buildlayout, which is often erroneously referred to as "the whole directory layout". In reality, in order to build the externals with the Pd-extended build system, you need:
externals/ pd/ packages/Makefile.buildlayout
That doesn't seem like much of a burden to me. We've spent far more time discussing that pesty package/Makefile.buildlayout that it would have taken just to check it out wherever its needed. That is not to say that improvements can't be made. There is much that could be done, this is just the beginning. I think that it might make sense to have all of a library's targets in its own local file, which then includes other global files for global things. But that would take quite a bit of work to create.
.hc
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
In reality, in order to build the externals with the Pd-extended build system, you need:
externals/ pd/ packages/Makefile.buildlayout
That doesn't seem like much of a burden to me.
Thanks for clarifying this. I agree that this isn't much of a burden.
Ciao
Agreed - thanks for the clarification HC - I didn't understand the build process either.
now.. what would be *really* nice would be if fresh versions all of the externals could be "apt-gotten" with apt-get (I guess this would be linux-only).. It's become quite convenient on Ubuntu to type:
apt-get update apt-get install puredata pd-zexy
..and have it all just work. :) Anyone know if this is easy to set up?
-David M.
On 8/9/06, Frank Barknecht fbar@footils.org wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
In reality, in order to build the externals with the Pd-extended build system, you need:
externals/ pd/ packages/Makefile.buildlayout
That doesn't seem like much of a burden to me.
Thanks for clarifying this. I agree that this isn't much of a burden.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Well, I am in the process of working with Nando, the PlanetCCRMA creator. We are building the new PlanetCCRMA Pd packages directly from the Pd-extended build system. So far its mostly working pretty well. I think this model would work well for the debian packages.
You can already easily redirect every library's install target using $ (DESTDIR) and $(prefix) per the GNU standards. So the Debian build could just do something like:
make DESTDIR=/path/to/build/zexy prefix=/usr zexy_install
make DESTDIR=/path/to/build/pdp prefix=/usr pdp_install
make DESTDIR=/path/to/build/pidip prefix=/usr pidip_install
make DESTDIR=/path/to/build/maxlib prefix=/usr maxlib_install
etc. etc. Then each lib will be built as a distinct Debian package.
.hc
On Aug 9, 2006, at 6:14 PM, David Merrill wrote:
Agreed - thanks for the clarification HC - I didn't understand the build process either.
now.. what would be *really* nice would be if fresh versions all of the externals could be "apt-gotten" with apt-get (I guess this would be linux-only).. It's become quite convenient on Ubuntu to type:
apt-get update apt-get install puredata pd-zexy
..and have it all just work. :) Anyone know if this is easy to set up?
-David M.
On 8/9/06, Frank Barknecht fbar@footils.org wrote: Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
In reality, in order to build the externals with the Pd-extended build system, you need:
externals/ pd/ packages/Makefile.buildlayout
That doesn't seem like much of a burden to me.
Thanks for clarifying this. I agree that this isn't much of a burden.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
On Wed, 9 Aug 2006, David Merrill wrote:
now.. what would be *really* nice would be if fresh versions all of the externals could be "apt-gotten" with apt-get (I guess this would be linux-only).. It's become quite convenient on Ubuntu to type:
apt-get update apt-get install puredata pd-zexy
..and have it all just work. :) Anyone know if this is easy to set up?
It is quite easy to setup an external debian package repository, but getting the packages into Debian/Ubuntu is a bit harder (remember the Gem borkage on Ubuntu ?), and I still haven't decided how/if to go about it.
There are several issues I am not feeling very comfortable about, and considering that doing the packaging of pd stuff for Debian has been a rather rewardless job in the past I doubt that I will take that burden.
I think the best would be if we do Debian packages for an external apt-gettable repository, this would also make it easier to keep them up to date etc.
Günter
-David M.
On 8/9/06, Frank Barknecht fbar@footils.org wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
In reality, in order to build the externals with the Pd-extended build system, you need:
externals/ pd/ packages/Makefile.buildlayout
That doesn't seem like much of a burden to me.
Thanks for clarifying this. I agree that this isn't much of a burden.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
On Aug 9, 2006, at 5:24 PM, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
In reality, in order to build the externals with the Pd-extended build system, you need:
externals/ pd/ packages/Makefile.buildlayout
That doesn't seem like much of a burden to me.
Thanks for clarifying this. I agree that this isn't much of a burden.
Its not ideal but it works solidly. To get really specific, you could do this:
cvs co externals/Makefile cvs co externals/maxlib cvs co pd/src cvs co packages/Makefile.buildlayout
cd externals && make maxlib
So you wouldn't really need that much from CVS.
.hc
------------------------------------------------------------------------
If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of everyone, and the receiver cannot dispossess himself of it. - Thomas Jefferson
-
David Merrill -
Frank Barknecht -
geiger -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
Thomas Grill