Hello all,
I am new to this list but met Hans and others at ISCL in Brazil a few weeks ago. Maybe this subject was discussed earlier, and if so, please forgive me.
I was looking through pd-extended build farm, scripts and compilation stuff. A good idea, actually, but difficult to maintain or distribute through many maintainers, as debian project does. Going on this direction, I would like to propose "a debian way" to package pd, abstractions and extra externals. This intention is related to many AMD64 problems on installing, compiling and using pd-extended. My sugestion is to use something like that:
puredata - puredata binaries and main documentation puredata-dev - include files and libs puredata-doc - extra documentation puredata-ext-XX - package containing a single external puredata-abs-XX - package containing a single abstraction puredata-full - a metapackage with all packages in Depedencies list
Why do this?
1) You can build everything separetely. This prevents that one bug in one package breaks all the building farm 2) Many people can manage packages in a distributed way and minimize Hans work 3) We can put these packages on debian official repo if we follow debian policy 4) Users does not have to install all externals/abstractions, as we have in pd-extended 5) We separate pd-source from the extra stuff 6) We can build a simple manual to patch developers create her own packages and distribute to users to install with an apt-get
I already started doing this with pd vanilla and one external (ff) to test these ideas and it is working on AMD64.
http://ftp.sacix.org/sacix/pool/main/p/puredata/ http://ftp.sacix.org/sacix/pool/main/p/pd-ff/
what do you think about it?
Bye, global
Anderson Goulart wrote:
Hello all,
puredata-ext-XX - package containing a single external puredata-abs-XX - package containing a single abstraction
why do you want to separate them? how does a "single external" differ (substantially) from a "single abstraction"? (esp. since .deb takes care of platform-in/dependency)
do you really want to distribute a _single_ file with an entire .deb or do you rather mean "library"?
how does this integrate into the already existing debian infrastructure for Pd? e.g. with naming schemes like "pd-zexy" or "pd-gem" (that is: why do we want to reinvent the wheel?)
fgmasdr IOhannes
Hello IOhannes,
thanks for your answer...
On Mon, Sep 21, 2009 at 4:08 AM, IOhannes m zmoelnig zmoelnig@iem.atwrote:
Anderson Goulart wrote:
Hello all,
puredata-ext-XX - package containing a single external
puredata-abs-XX - package containing a single abstraction
why do you want to separate them?
how does a "single external" differ (substantially) from a "single
abstraction"? (esp. since .deb takes care of platform-in/dependency)
Well, this is just an ideia and we can decide to use names like puredata-xxx, where xxx is the name of external/abstraction. What I want here is to discuss the conventions about packaging things related to Pd.
do you really want to distribute a _single_ file with an entire .deb or do you rather mean "library"?
Maybe we can distribute a "library" if those externals/abstractions are related. But if they are different, with different upstream authors, with different dependencies and different funcionalities, I think distribute an entire .deb is better than put it together in a library.
how does this integrate into the already existing debian infrastructure for Pd? e.g. with naming schemes like "pd-zexy" or "pd-gem" (that is: why do we want to reinvent the wheel?)
I am not a debian developer, but I am sure we can talk to them to upload all packages to the official repo. The naming conventions are just suggestions and we can use pd-xxx instead of puredata-xxx. The main idea of this email is to separate pd-extended into some .deb packages to become more clear and easier to maintain to many architectures and distribution versions.
bye, global
Hey Anderson,
Its good timing for bringing these up, Günter has stopped maintaining his official Debian packages, so they are officially orphaned right now. Anyone here a Debian Developer? I am starting the process of becoming a Debian Developer (and I'll be helping to run DebCof 2010 in NYC next summer). We could start a Pd group for packaging all this stuff.
I think that the 'puredata' and pure:dyne packages would be the best place to start, then they just need to be tailored to be more Debian- proper (i.e. moving all non-libs out of /usr/lib/pd, etc.) and work with the 'pd' virtual package. I
Plus dmotd, IOhannes, me and others are working on rewriting build system so it should be easier to package the libraries individually.
.hc
On Sep 21, 2009, at 8:43 AM, Anderson Goulart wrote:
Hello IOhannes,
thanks for your answer...
On Mon, Sep 21, 2009 at 4:08 AM, IOhannes m zmoelnig zmoelnig@iem.at wrote: Anderson Goulart wrote: Hello all,
puredata-ext-XX - package containing a single external puredata-abs-XX - package containing a single abstraction
why do you want to separate them? how does a "single external" differ (substantially) from a "single abstraction"? (esp. since .deb takes care of platform-in/dependency)
Well, this is just an ideia and we can decide to use names like puredata-xxx, where xxx is the name of external/abstraction. What I want here is to discuss the conventions about packaging things related to Pd.
do you really want to distribute a _single_ file with an entire .deb or do you rather mean "library"?
Maybe we can distribute a "library" if those externals/abstractions are related. But if they are different, with different upstream authors, with different dependencies and different funcionalities, I think distribute an entire .deb is better than put it together in a library.
how does this integrate into the already existing debian infrastructure for Pd? e.g. with naming schemes like "pd-zexy" or "pd-gem" (that is: why do we want to reinvent the wheel?)
I am not a debian developer, but I am sure we can talk to them to upload all packages to the official repo. The naming conventions are just suggestions and we can use pd-xxx instead of puredata-xxx. The main idea of this email is to separate pd-extended into some .deb packages to become more clear and easier to maintain to many architectures and distribution versions.
bye, global _______________________________________________ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
----------------------------------------------------------------------------
As we enjoy great advantages from inventions of others, we should be glad of an opportunity to serve others by any invention of ours; and this we should do freely and generously. - Benjamin Franklin
Hi Hans,
On Mon, Sep 21, 2009 at 11:58 AM, Hans-Christoph Steiner hans@at.or.atwrote:
Hey Anderson,
Its good timing for bringing these up, Günter has stopped maintaining his official Debian packages, so they are officially orphaned right now. Anyone here a Debian Developer? I am starting the process of becoming a Debian Developer (and I'll be helping to run DebCof 2010 in NYC next summer). We could start a Pd group for packaging all this stuff.
This is why I got here... many friends who are working with Pd from a long time told me some problems on installing pd-extended on other plattaforms. And I thought I can help on this... I tried to use the build-farm with no success... it is a huge script and the build files of some externals are so complicated that I could not compile them... I am studying a lot about autotools, compiler, linker stuff and debian packaging to solve those problems...
I think that the 'puredata' and pure:dyne packages would be the best place to start, then they just need to be tailored to be more Debian-proper (i.e. moving all non-libs out of /usr/lib/pd, etc.) and work with the 'pd' virtual package. I
This is what I am trying to do right now... As you know, I am a new user of Pd but an old user and C and package developer... now I am working with Pd and the problems with pd-extended on AMD64 lead me to think about rewriting or rethinking the way of packaging...
Plus dmotd, IOhannes, me and others are working on rewriting build system so it should be easier to package the libraries individually.
The big problem I see here is: you and others made a very big build system with incredible worth.. my proposal maybe will break many things that you already did, as the build farm will change to build so many small deb packages for many distributions and archs.
The work of doing this big changes worth? That is the question we might ask ourselves. Looking beyond the cave I really think YES. Some years ago, when developing Sacix distribution, I had to make a similar decision. I decided to change my way of building packages from a monolitic to a "distributed" way.. well, I spent 6 months of intense work, too many bugs, broke dependencies, etc. I got a little bit crazy with all those problems and packages, but now I can breath and spend more time on the beach. :D
Maybe the best way is to work in parallel, maintain the pd-extended and create a separate repo with all deb packages and this new experience ... this new repo will need I huge work, I know, but my experience told me that worth.
I have about 40 packages in sacix distribution to maintain. How this works to build all of them? I have a simple build script that enters in the directory of the package, run debuild command and go to another one.. I can skip some of them if it is broken just adding the package to a shell var. Today, the only work is to upgrade the package if a new version of the software is released (like firefox). Of course many packages are configuration only, so this almost does not change.
I am gonna lunch.. after that I will try to answer dmotd...
bye, global
i guess i understand where you're coming from and in some ways i think you are right, however packaging debs is not as simple as it seems and with the sheer size of the externals repo what you are suggesting would get quite unmanageable.
for the record, i am currently working on a slightly revised build system and part of the aim of that is to modularize the building process, so that assembling pd as a series of parts will become easier and more configurable. automating a set of debian rules would hopefully be a lot less time consuming once this work is complete.
this may knock over a part of the problem, but there are a lot of libraries that require less generalized appoaches and need careful attention from a packager (which can become a time consuming role).
this is part of the reason why pd-extended is a very successful package - it knocks out a lot of the maintenance hastles by automating as much of the build procedure as possible, and although as a whole it is quite monalythic, the same set of objects can be reliably assumed across each platform (or in linux terms each variety of distribution). it's not perfect but it makes sense for most people - and many thanks to hans for getting it this far (its a pretty thankless job).
perhaps what should be asked is what is required from pd to make it a full featured language for people to practically use it for whatver meets a general set of needs? for many people what miller packages as his own 'vanilla' set is all that is required and everything else is extraneous. for a lot of people with complex goals that just doesn't cut it and extended is necessary to work beyond pd's own limitations.
or pehaps pd could go down the path of perl/cpan, php/pear etc, where extra non-base libs are housed in a dedicated on demand server where users can automagically fetch / compile and install extras outside of the confines of a package manager.
or do you want there to be categorized libs for different areas of programming, what should be installed by default with the meta package, and what happens to objects that don't neatly slot into a category - or worse fulfil a number of categories?
these are just a few arguments that i think are stumbling blocks for your proposal. its not to say that its a dumb idea, but perhaps a little simplistic and something which has already met a lot of conentious discussion on this and other forums.
but if you care to go over some of your ideas with a bit more detail we may find something interesting to work with. -- dmotd.
Anderson Goulart wrote:
Hello IOhannes,
thanks for your answer...
On Mon, Sep 21, 2009 at 4:08 AM, IOhannes m zmoelnig zmoelnig@iem.at wrote:
Anderson Goulart wrote: Hello all, puredata-ext-XX - package containing a single external puredata-abs-XX - package containing a single abstraction why do you want to separate them? how does a "single external" differ (substantially) from a "single abstraction"? (esp. since .deb takes care of platform-in/dependency)
Well, this is just an ideia and we can decide to use names like puredata-xxx, where xxx is the name of external/abstraction. What I want here is to discuss the conventions about packaging things related to Pd.
do you really want to distribute a _single_ file with an entire .deb or do you rather mean "library"?
Maybe we can distribute a "library" if those externals/abstractions are related. But if they are different, with different upstream authors, with different dependencies and different funcionalities, I think distribute an entire .deb is better than put it together in a library.
how does this integrate into the already existing debian infrastructure for Pd? e.g. with naming schemes like "pd-zexy" or "pd-gem" (that is: why do we want to reinvent the wheel?)
I am not a debian developer, but I am sure we can talk to them to upload all packages to the official repo. The naming conventions are just suggestions and we can use pd-xxx instead of puredata-xxx. The main idea of this email is to separate pd-extended into some .deb packages to become more clear and easier to maintain to many architectures and distribution versions.
bye, global
On 21/09/2009, at 16.59, dmotd wrote:
or pehaps pd could go down the path of perl/cpan, php/pear etc, where extra non-base libs are housed in a dedicated on demand server where users can automagically fetch / compile and install extras outside of the confines of a package manager.
how much work do you think that would be? - i'm just curious.
could the installer be a "script" that would live where the modular plugin-script for the gui live -- and in that way not conflict nor demand anything from millers branch?
Steffen Juul wrote:
On 21/09/2009, at 16.59, dmotd wrote:
or pehaps pd could go down the path of perl/cpan, php/pear etc, where extra non-base libs are housed in a dedicated on demand server where users can automagically fetch / compile and install extras outside of the confines of a package manager.
how much work do you think that would be? - i'm just curious.
could the installer be a "script" that would live where the modular plugin-script for the gui live -- and in that way not conflict nor demand anything from millers branch?
hi steffen,
i'm not particularly advocating this strategy, but thought i'd bring this up as another method of delivery.
certainly these engines are not trivial, there is probably more careful design considerations with on-demand delivery than has been made with the entire extended builder!
i haven't done any real research on existing technologies apart from being a casual user of the two listed above, so i am in no position to argue its merits or the time involved in putting such a thing together.
but such a repository could be a real boost to the pd community, as it could aid individuals to promote their objects and abstractions, provide a convenient method of searching, provide methods of dependency tracking for more involved abstactions, and provide an infrustructure for the distribution of whole pd 'programs'.
this approach is not without its pitfalls and methods for installation and removal would need to be watertight, not to mention the security risks of downloading and installing from a client application.
but at the same time, its something that could exist parallel to other methods of distribution, and may turn out to be quite popular?
so i guess i'd certainly support any investigation into an on-demand client/server.
cheers, dmotd
Hello dmotd,
On Mon, Sep 21, 2009 at 11:59 AM, dmotd inaudible@simplesuperlativ.eswrote:
i guess i understand where you're coming from and in some ways i think you are right, however packaging debs is not as simple as it seems and with the sheer size of the externals repo what you are suggesting would get quite unmanageable.
why do you think so? Manage the repo is easy.. reprepro can do this for us easily... the dificult part will be generate debian/ dir to all externals and make a standard to put things on the correct places... in this part I think that would not be a big problem also, because all externals (or almost all) has autotools build system... with some templates we can manage a task force on the weekend to do this handfull job..
for the record, i am currently working on a slightly revised build system and part of the aim of that is to modularize the building process, so that assembling pd as a series of parts will become easier and more configurable. automating a set of debian rules would hopefully be a lot less time consuming once this work is complete.
ow... i would like to see what you are doing.. maybe will help us to separate things.. can you share?
this may knock over a part of the problem, but there are a lot of libraries that require less generalized appoaches and need careful attention from a packager (which can become a time consuming role).
so.. on those packages we can distribute the work to someone with more expertise or we can help each other to manage that... but, with separate things, it is easier to deal with a problem than in a huge build farm .. .
this is part of the reason why pd-extended is a very successful package - it knocks out a lot of the maintenance hastles by automating as much of the build procedure as possible, and although as a whole it is quite monalythic, the same set of objects can be reliably assumed across each platform (or in linux terms each variety of distribution). it's not perfect but it makes sense for most people - and many thanks to hans for getting it this far (its a pretty thankless job).
pd-extended is successful because users can install and use it... they do not care about what kind of build systems the developers are using or dealing with... I think hans made a very good work, but increasing the number of packages will become harder to maintain in a monolict way.. that's my opinion...
perhaps what should be asked is what is required from pd to make it a full featured language for people to practically use it for whatver meets a general set of needs? for many people what miller packages as his own 'vanilla' set is all that is required and everything else is extraneous. for a lot of people with complex goals that just doesn't cut it and extended is necessary to work beyond pd's own limitations.
so we got the point... the users view is the key... all of the work is done for them... because for us we can just compile all the stuff ourselves.. as a user, pd-extended installs and load too much externals.. why can't we do such a thing that the user can choose what he wants? Like: i need pd+gem+fann ... can I have it only?
or pehaps pd could go down the path of perl/cpan, php/pear etc, where extra non-base libs are housed in a dedicated on demand server where users can automagically fetch / compile and install extras outside of the confines of a package manager.
Maybe it is a good idea, but i have no idea how they built this server.. and thinking in users, it is easier to install via apt-get than cpan specific commands.. because who uses debian/ubuntu are used to it.
or do you want there to be categorized libs for different areas of programming, what should be installed by default with the meta package, and what happens to objects that don't neatly slot into a category - or worse fulfil a number of categories?
well.. meta-packages or categories are just a user point of view.. we can create many as we or users want... like
pd-full pd-audio pd-video pd-math ...
this is not a problem at all..
these are just a few arguments that i think are stumbling blocks for your proposal. its not to say that its a dumb idea, but perhaps a little simplistic and something which has already met a lot of conentious discussion on this and other forums.
I think a simplistic way is the best way.. always.. :D Why transform a simple step harder or more complex? But I really understand the work you, Hans and others had in pd packaging and this is why I just throw the dicussion here.. I needed to know what is going on before working alone on an idea...
but if you care to go over some of your ideas with a bit more detail we may find something interesting to work with.
I think I was clear about my ideas. Make a debian package for every external or join only some related to a deb file.
And there are some others key points:
1) make a single documentation teaching how developers can build or create their own packages 2) remove "m_pd.h" from externals and use <m_pd.h> (why do I need to have PD source to compile my external? This should be installed as any other library and linked with -l option; the m_pd.h should be installed on /usr/include also) 3) fix many build systems to work in any platafform (like adding -fPIC for AMD64 every time we need to compile on this plattaform is so anoying.. we can make it automatic or add something like --arch option) 3.1) Some build systems use a variable to point where is the pd source. This is bizarre for me... let's make a pd shared library and link to it... 4) distribute some files: .orig.tar.gz with the clean source to help others to create their own build (like ebuild on gentoo or slackpkg) .dsc and deb - debianized package
that is it for now..
bye, global
please make sure you cc pd-dev too!
Anderson Goulart wrote:
Hello dmotd,
On Mon, Sep 21, 2009 at 11:59 AM, dmotd inaudible@simplesuperlativ.es wrote:
i guess i understand where you're coming from and in some ways i think you are right, however packaging debs is not as simple as it seems and with the sheer size of the externals repo what you are suggesting would get quite unmanageable.
why do you think so? Manage the repo is easy.. reprepro can do this for us easily... the dificult part will be generate debian/ dir to all externals and make a standard to put things on the correct places... in this part I think that would not be a big problem also, because all externals (or almost all) has autotools build system... with some templates we can manage a task force on the weekend to do this handfull job..
for the record, i am currently working on a slightly revised build system and part of the aim of that is to modularize the building process, so that assembling pd as a series of parts will become easier and more configurable. automating a set of debian rules would hopefully be a lot less time consuming once this work is complete.
ow... i would like to see what you are doing.. maybe will help us to separate things.. can you share?
this may knock over a part of the problem, but there are a lot of libraries that require less generalized appoaches and need careful attention from a packager (which can become a time consuming role).
so.. on those packages we can distribute the work to someone with more expertise or we can help each other to manage that... but, with separate things, it is easier to deal with a problem than in a huge build farm .. .
this is part of the reason why pd-extended is a very successful package - it knocks out a lot of the maintenance hastles by automating as much of the build procedure as possible, and although as a whole it is quite monalythic, the same set of objects can be reliably assumed across each platform (or in linux terms each variety of distribution). it's not perfect but it makes sense for most people - and many thanks to hans for getting it this far (its a pretty thankless job).
pd-extended is successful because users can install and use it... they do not care about what kind of build systems the developers are using or dealing with... I think hans made a very good work, but increasing the number of packages will become harder to maintain in a monolict way.. that's my opinion...
perhaps what should be asked is what is required from pd to make it a full featured language for people to practically use it for whatver meets a general set of needs? for many people what miller packages as his own 'vanilla' set is all that is required and everything else is extraneous. for a lot of people with complex goals that just doesn't cut it and extended is necessary to work beyond pd's own limitations.
so we got the point... the users view is the key... all of the work is done for them... because for us we can just compile all the stuff ourselves.. as a user, pd-extended installs and load too much externals.. why can't we do such a thing that the user can choose what he wants? Like: i need pd+gem+fann ... can I have it only?
or pehaps pd could go down the path of perl/cpan, php/pear etc, where extra non-base libs are housed in a dedicated on demand server where users can automagically fetch / compile and install extras outside of the confines of a package manager.
Maybe it is a good idea, but i have no idea how they built this server.. and thinking in users, it is easier to install via apt-get than cpan specific commands.. because who uses debian/ubuntu are used to it.
or do you want there to be categorized libs for different areas of programming, what should be installed by default with the meta package, and what happens to objects that don't neatly slot into a category - or worse fulfil a number of categories?
well.. meta-packages or categories are just a user point of view.. we can create many as we or users want... like
pd-full pd-audio pd-video pd-math ...
this is not a problem at all..
these are just a few arguments that i think are stumbling blocks for your proposal. its not to say that its a dumb idea, but perhaps a little simplistic and something which has already met a lot of conentious discussion on this and other forums.
I think a simplistic way is the best way.. always.. :D Why transform a simple step harder or more complex? But I really understand the work you, Hans and others had in pd packaging and this is why I just throw the dicussion here.. I needed to know what is going on before working alone on an idea...
but if you care to go over some of your ideas with a bit more detail we may find something interesting to work with.
I think I was clear about my ideas. Make a debian package for every external or join only some related to a deb file.
And there are some others key points:
- make a single documentation teaching how developers can build or create
their own packages 2) remove "m_pd.h" from externals and use <m_pd.h> (why do I need to have PD source to compile my external? This should be installed as any other library and linked with -l option; the m_pd.h should be installed on /usr/include also) 3) fix many build systems to work in any platafform (like adding -fPIC for AMD64 every time we need to compile on this plattaform is so anoying.. we can make it automatic or add something like --arch option) 3.1) Some build systems use a variable to point where is the pd source. This is bizarre for me... let's make a pd shared library and link to it... 4) distribute some files: .orig.tar.gz with the clean source to help others to create their own build (like ebuild on gentoo or slackpkg) .dsc and deb - debianized package
that is it for now..
bye, global
dmotd wrote:
please make sure you cc pd-dev too!
oh i'm sorry, it seems that something is wrong with my mail delivery - i checked the archives and messages recieved only to my personal inbox did make it to pd-dev i just didn't recieve them from pd-dev and some messages from pd-dev never made it at all? odd.
dmotd wrote:
dmotd wrote:
please make sure you cc pd-dev too!
oh i'm sorry, it seems that something is wrong with my mail delivery - i checked the archives and messages recieved only to my personal inbox did make it to pd-dev i just didn't recieve them from pd-dev and some messages from pd-dev never made it at all? odd.
even: http://www.list.org/mailman-member/node21.html this is enabled by default for all new subscribers.
fgmasdr IOhannes
IOhannes m zmoelnig wrote:
dmotd wrote:
dmotd wrote:
please make sure you cc pd-dev too!
oh i'm sorry, it seems that something is wrong with my mail delivery - i checked the archives and messages recieved only to my personal inbox did make it to pd-dev i just didn't recieve them from pd-dev and some messages from pd-dev never made it at all? odd.
even: http://www.list.org/mailman-member/node21.html this is enabled by default for all new subscribers.
fgmasdr IOhannes
thanks IOhannes,
i should have checked the options when i subscribed my current email.. that would certainly explain it.
dmotd
First off, just to be clear, I don't think anyone wants to keep the big monolithic build system or the package. Its a big hack/kludge that is not maintainable going forward. I answered some other random questions below as well.
On Sep 21, 2009, at 6:16 PM, Anderson Goulart wrote:
And there are some others key points:
- make a single documentation teaching how developers can build or
create their own packages
Yes!
- remove "m_pd.h" from externals and use <m_pd.h> (why do I need to
have PD source to compile my external? This should be installed as any other library and linked with -l option; the m_pd.h should be installed on /usr/include also)
sounds good
- fix many build systems to work in any platafform (like adding -
fPIC for AMD64 every time we need to compile on this plattaform is so anoying.. we can make it automatic or add something like --arch option)
sounds good
3.1) Some build systems use a variable to point where is the pd source. This is bizarre for me... let's make a pd shared library and link to it...
This is how it is done already on Windows.
- distribute some files:
.orig.tar.gz with the clean source to help others to create their own build (like ebuild on gentoo or slackpkg) .dsc and deb - debianized package
sounds good.
- One the libs are split into their own packages, 'pd-extended' could then be a package like 'puredata' that provides 'pd'. Perhaps there would be a 'desiredata' package in the future that also provides 'pd'. 'pd-extended' could then require the standard libs, so that installing Pd-extended on all platforms gives you the same libraries.
- It would be quite useful having each library have its own release cycle and version number.
- the planetCCRMA packages are based on the Pd-extended build system but just package things differently.
- Windows and Mac OS X builds would remain as one big package unless there is a CPAN-type system developed for Pd.
----------------------------------------------------------------------------
Looking at things from a more basic level, you can come up with a more direct solution... It may sound small in theory, but it in practice, it can change entire economies. - Amy Smith
Hans-Christoph Steiner wrote:
- remove "m_pd.h" from externals and use <m_pd.h> (why do I need to
have PD source to compile my external? This should be installed as any other library and linked with -l option; the m_pd.h should be installed on /usr/include also)
sounds good
hmm, Debian's official "pd" package already installs m_pd.h into /usr/include/.
personally i have long been voting for an official "pd.h" header, rather than having the "m_" stuff lying around in my official includes.
for the PD_SRC, see below.
3.1) Some build systems use a variable to point where is the pd source. This is bizarre for me... let's make a pd shared library and link to it...
i don't see it so bizarre. there are two reasons for using a PD_SRC variable: - first: m_pd.h is not installed on your system and you still want to compile the external. or you want to compile your external against a version of Pd that is not the same as the one officially installed. this is something a developer comes along quite often.
- second, and this is more important: some externals depend on "private" headers of Pd (s_stuff.h, m_imp.h); now one can argue that it is bad style (though not necessarily "bizarre") to depend on private headers - it's fine for me but for some interesting objects there is no way around these private headers (personally, i think of iemguts; or all of the loaders; or...); it would get bizarre to put the "s_stuff.h" into /usr/include :-)
(ah yes, put everything into /usr/include/pd/ and then use pkg-config to add /usr/include/pd to your path - this is a very standard way for keeping /usr/include tidy and it is indeed quite similar to what people are using the PD_SRC for)
finally, your conclusion seems to be more bizarre than the problem. these PD_SRC variables point to the sources, not to the binaries. i don't see how making a shared library (which is a binary) will help you at all here. (e.g. on linux i never "link" against Pd; but on all platforms i do need the headers)
This is how it is done already on Windows.
which is true and good, but (as pointed out above) unrelated to the variable pointing to the Pd source.
- Windows and Mac OS X builds would remain as one big package unless
there is a CPAN-type system developed for Pd.
i agree (and honestly i don't think a CPAN-like system will happen anytime soon).
fmgasdr IOhannes
On Sep 22, 2009, at 12:38 PM, IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
- remove "m_pd.h" from externals and use <m_pd.h> (why do I need
to have PD source to compile my external? This should be installed as any other library and linked with -l option; the m_pd.h should be installed on /usr/include also)
sounds good
hmm, Debian's official "pd" package already installs m_pd.h into / usr/include/.
personally i have long been voting for an official "pd.h" header, rather than having the "m_" stuff lying around in my official includes.
for the PD_SRC, see below.
I also support just a 'pd.h' but there will be quite a bit of hassle with that. The package could include a pd.h symlink to m_pd.h to start with.
3.1) Some build systems use a variable to point where is the pd source. This is bizarre for me... let's make a pd shared library and link to it...
i don't see it so bizarre. there are two reasons for using a PD_SRC variable:
- first: m_pd.h is not installed on your system and you still want
to compile the external. or you want to compile your external against a version of Pd that is not the same as the one officially installed. this is something a developer comes along quite often.
- second, and this is more important: some externals depend on
"private" headers of Pd (s_stuff.h, m_imp.h); now one can argue that it is bad style (though not necessarily "bizarre") to depend on private headers - it's fine for me but for some interesting objects there is no way around these private headers (personally, i think of iemguts; or all of the loaders; or...); it would get bizarre to put the "s_stuff.h" into /usr/include :-)
(ah yes, put everything into /usr/include/pd/ and then use pkg- config to add /usr/include/pd to your path - this is a very standard way for keeping /usr/include tidy and it is indeed quite similar to what people are using the PD_SRC for)
finally, your conclusion seems to be more bizarre than the problem. these PD_SRC variables point to the sources, not to the binaries. i don't see how making a shared library (which is a binary) will help you at all here. (e.g. on linux i never "link" against Pd; but on all platforms i do need the headers)
This is how it is done already on Windows.
which is true and good, but (as pointed out above) unrelated to the variable pointing to the Pd source.
- Windows and Mac OS X builds would remain as one big package
unless there is a CPAN-type system developed for Pd.
i agree (and honestly i don't think a CPAN-like system will happen anytime soon).
It will happen as soon as someone does it. :D I don't think anyone objects to the idea, right?
.hc
----------------------------------------------------------------------------
I hate it when they say, "He gave his life for his country." Nobody gives their life for anything. We steal the lives of these kids. - Admiral Gene LeRocque
Hans-Christoph Steiner wrote:
i agree (and honestly i don't think a CPAN-like system will happen anytime soon).
It will happen as soon as someone does it. :D I don't think anyone objects to the idea, right?
well, like always - i do :-)
i agree with dmotd, that such a thing has to be thought through _very_ carefully. it's easy to hack together something dirty. e.g. cygwins package management system is just something i would never ever like to encounter again.
but honestly: personally as a debian user (being nurtured with apt) i am not a great friend of all these concurrent packaging systems; e.g. python-eggs/buildouts do cause me a lot of headache, because they don't integrate into apt (or any other concurrent package-manager, i guess) at all. i don't want to get Pd into the same hell....
fgmasdr IOhannes
On Sep 22, 2009, at 1:04 PM, IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
i agree (and honestly i don't think a CPAN-like system will happen anytime soon).
It will happen as soon as someone does it. :D I don't think anyone objects to the idea, right?
well, like always - i do :-)
i agree with dmotd, that such a thing has to be thought through _very_ carefully. it's easy to hack together something dirty. e.g. cygwins package management system is just something i would never ever like to encounter again.
but honestly: personally as a debian user (being nurtured with apt) i am not a great friend of all these concurrent packaging systems; e.g. python-eggs/buildouts do cause me a lot of headache, because they don't integrate into apt (or any other concurrent package- manager, i guess) at all. i don't want to get Pd into the same hell....
Well, not everyone in the world uses Debian.... whether or not they should is a different question. Things like CPAN quite possibly predate debian, since we would be starting post-Debian, we could just use Debian packages internally for Pd.
.hc
----------------------------------------------------------------------------
Computer science is no more related to the computer than astronomy is related to the telescope. -Edsger Dykstra
IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
i agree (and honestly i don't think a CPAN-like system will happen anytime soon).
It will happen as soon as someone does it. :D I don't think anyone objects to the idea, right?
well, like always - i do :-)
i agree with dmotd, that such a thing has to be thought through _very_ carefully. it's easy to hack together something dirty. e.g. cygwins package management system is just something i would never ever like to encounter again.
but honestly: personally as a debian user (being nurtured with apt) i am not a great friend of all these concurrent packaging systems; e.g. python-eggs/buildouts do cause me a lot of headache, because they don't integrate into apt (or any other concurrent package-manager, i guess) at all. i don't want to get Pd into the same hell....
ya, there's no doubt in my mind that most of these CPAN style systems make existing packaging and general client maintenance an absolute nightmare, while at the server end help turn source repositories into dense catacombs, with deserted code being left under miles of unmaintained dependencies. and even if it is done well it risks becoming over-designed and difficult to manouvre, losing the flexibility that is supposed to be a gain.
but all this said there's something very attractive in the idea, which i think relates well to the pd environment. and there appears to be a growing demand for distribution of end-user targeted applications.
pd seems to have outgrown its initial reputation as a toy for artist/programmers tinkering and experimenting with sound and other media, and is getting more widespread use in rich and featureful applications - from dsp fx manipulators and vj applications to full fledged studio tools and artist installations (not to forget the rjdj project which obviously has distribution built into its concept). in many ways pure data forum~ superceded pd-announce list a while ago as a space for releasing pd based work.
as far as i know there is nothing publicly available that can quickly tell you the dependencies of a given pd patch, in terms of what libraries / objects / abstractions are missing (i do have a shell script that does something similar if anyone wants it). sure, simply loading the patch will shout a long list of errors, but it can be a little intimidating to anyone simply trying to get a pd-app to run without much background knowledge of the environment.
so perhaps its not too big a leap in the wrong direction to begin considering a distribution hub for pd based projects. it wouldn't have to build code initially, it could simply create a dependency tree, download any required abstractions and install them into its own jail and list any depencies that can't be met through the client/server alone. in this sense it wouldn't even need to be a shell script to begin with and could be contained in a web framework that assembles the elements into a tarball ready for convenient download. thus allowing the system to mature in a slow and contained way, rather than a quick and dirty shell based external mangler.
in a sense a project of this nature would be in some ways a natural meating point for existing projects like pdpedia, netpd and puredata forum~.
so i guess i'm cautiously welcome to the idea of adopting some distribution/packaging approaches, but there needs to be a lot more talk first.
--- dmotd
So with a couple of perhaps narrow-minded rants out of the way, I would like now to respond to dmotd.
i guess i understand where you're coming from and in some ways i think you are right, however packaging debs is not as simple as it seems and with the sheer size of the externals repo what you are suggesting would get quite unmanageable.
It might be a lot of work for one packager, but like any complex task it will be easier if you break it up into smaller ones. The Makefile in the externals directory of pd-extended seems unmanageable, to me. Have I misunderstood you here? I think modularity will help us all retain sanity in both implementation and maintenance.
for the record, i am currently working on a slightly revised build system and part of the aim of that is to modularize the building process, so that assembling pd as a series of parts will become easier and more configurable. automating a set of debian rules would hopefully be a lot less time consuming once this work is complete.
I would be interested in details.
this may knock over a part of the problem, but there are a lot of libraries that require less generalized appoaches and need careful attention from a packager (which can become a time consuming role).
Okay. All those Debian tools and Gentoo eclasses have functionality to deal with tricky packages. If the library needs a lot of configuration, then it may not be a problem with the library or its build system, but a necessary challenge to the packager. Even now some externals fit nicely into the template in the Makefile and some need customization by there very nature.
this is part of the reason why pd-extended is a very successful package - it knocks out a lot of the maintenance hastles by automating as much of the build procedure as possible, and although as a whole it is quite monalythic, the same set of objects can be reliably assumed across each platform (or in linux terms each variety of distribution). it's not perfect but it makes sense for most people - and many thanks to hans for getting it this far (its a pretty thankless job).
Yes, thank you Hans for getting me some form of pd-extended, thus giving me the motivation to post here at all.
perhaps what should be asked is what is required from pd to make it a full featured language for people to practically use it for whatver meets a general set of needs? for many people what miller packages as his own 'vanilla' set is all that is required and everything else is extraneous. for a lot of people with complex goals that just doesn't cut it and extended is necessary to work beyond pd's own limitations.
I think extended is a good idea. I just think it would be better implemented in distribution repositories as meta-packages than on the source side.
or pehaps pd could go down the path of perl/cpan, php/pear etc, where extra non-base libs are housed in a dedicated on demand server where users can automagically fetch / compile and install extras outside of the confines of a package manager.
There are a lot of externals, but not that many :) And in that future, I would look at making something like g-cpan on Gentoo, which can build a Perl module from cpan and still have it appear in my portage tree, even for those modules which have no ebuild already written! (It is essentially a wrapper for the cpan shell.)
or do you want there to be categorized libs for different areas of programming, what should be installed by default with the meta package, and what happens to objects that don't neatly slot into a category - or worse fulfil a number of categories?
Again I think what gstreamer does might be interesting, and worth closer attention. They group their plugins based on stability/maturity.
nice to see a lot of discussion, i can't fathom replying to the various threads happening here as i am fairly time poor at present, but i thought i'd take the time to make my position as clear as possible before getting mixed up with any particular argument. apologies if i become a bit verbose!
so, lets just take a quick step back -
debian is one single operating system and packagers for debian can package pd in any way they wish, sliced, diced, recombined or with a flight simulator if they choose.
pd-extended could be assembled from parts as a meta package, there's no issue there.
as long as a user of extended on windows or osx can run their patch on a debian linux machine without a diminished experience then there should be no concern for how their version of extended was assembled.
so this i am all quite happy with!!
but, while the debian way is good for debian, its not the same fit for other environments. a user of windows doesn't have the same packaging comforts as apt-get and feels far more comfortable with an assembled installer, sure they could pick and choose their parts, but part of the luxury of extended is that its mostly all there and from a new user perspective this makes it instantly more rewarding than a blank canvas with hundreds of unknown installable modules.
but there are alternatives to extended.. planet ccrma has been a very reliable package set for a number of fedora users and i think this may be on a similar tangent to what both anderson and tim are proposing here for debian. similarly pure:dyne maintains their own version of pd, but in a different manner - also worth looking at.
i too agree that a monalythic build system does not make sense for long term maintainability, and makes pd as an environment far less configurable for specific needs - but i still support the existence and sustained efforts at packaging pd-extended, it just can be assembled better with greater modularity (making it a template of sorts).
what is important is that pd and its externals build evenly for the multitude of different platforms and that there is no bias towards individual operating systems. this is a balance that hans has very carefully respected with extended, iohannes and co have maintained with gem and what miller generously started with pd.
and that's why i am working on reshaping the existing build environments to become more modular, in which there is a method for building each lib as a self contained vessel from its own directory (tarball or whatever), while allowing each lib to be tightly woven into any number of custom builders seamlessly.
the inspiration is not mine and the initial groundwork was conducted by IOhannes and hans as a proof of concept demonstrated in the ext13 library (as well as motex and apple). i have been working on methods to make this template more managable for complex projects, better integrated into modular build *systems* and simpler to engage with for both newbies and devs alike. it should also make creating custom maintainer scripts much simpler.
i am not so concerned with any particular packaging system, what i am interested in is a simple configurable modular system that builds and installs source into a given tree / jail or whatever you like to call it, in the same manner for each target platform, while also providing useful tools for gathering information and tests for libs, objects and reference material.
what package maintainers do to integrate their needs is entirely up to them, but should be done in such a way without touching the behaviour of the overall build mechanism, rather simply extending its functionality through modular scripts and wrappers.
debian is one world view, its one i have used before, but not one i subscribe to currently myself, so please excuse my naivety when it comes to the inner workings and build semantics of a debian machine. i am however, cautious when it comes to mixing ideologies (or stubborn attitudes) of a certain 'way' with a system which should ideally provide simple navigation for a number of 'ways'. as long as there is respect for different methods then the debian gods can also get their way ;)
anyhow, i have been making steady progress over the previous weeks and i should have a snapshot ready shortly for perusal. if you want to talk directly about my work on the buildsystem i frequent the #dataflow channel of irc.freenode.org along with hans and a number of others. sorry i can't be more explicit with what i am assembling but it's still a bit of shifting target. i also have a dayjob - so this work is divided around scattered freetime so i hope it doesn't seem painfully slow, there'll be something to digest and potentially hack about with soon, so patience is appreciated. my methods may be rubish too, but i have given it a fair bit of consideration, and so too have others, so in this case i think improvement is a better solution than straight up reinvention (but its always exciting to be proved wrong!!).
thanks! dmotd
pd-extended could be assembled from parts as a meta package, there's no issue there.
I guess my point is that, if I download the pd-extended tarball, it is not easy at all to assemble it as a series of parts, not as easy and efficient as it could be. At the very least, I think there needs to be some housekeeping done.
as long as a user of extended on windows or osx can run their patch on a debian linux machine without a diminished experience then there should be no concern for how their version of extended was assembled.
Correct! I think Anderson and I are complaining strictly as packagers.
but, while the debian way is good for debian, its not the same fit for other environments. a user of windows doesn't have the same packaging comforts as apt-get and feels far more comfortable with an assembled installer, sure they could pick and choose their parts, but part of the luxury of extended is that its mostly all there and from a new user perspective this makes it instantly more rewarding than a blank canvas with hundreds of unknown installable modules.
All I'm asking for is increased modularity, which is more than just the debian way. Though admittedly I have no idea how Windows installers are built, but I don't think it would be difficult to have a check box or something that says "Install Everything! (Recommended, seriously. Default.)" What I'm really seeking is improvement on modularity for the _build_, not necessarily the package.
but there are alternatives to extended.. planet ccrma has been a very reliable package set for a number of fedora users and i think this may be on a similar tangent to what both anderson and tim are proposing here for debian. similarly pure:dyne maintains their own version of pd, but in a different manner - also worth looking at.
I'll have a look at these. (I'm working on Gentoo :)
i too agree that a monalythic build system does not make sense for long term maintainability, and makes pd as an environment far less configurable for specific needs - but i still support the existence and sustained efforts at packaging pd-extended, it just can be assembled better with greater modularity (making it a template of sorts).
Yesss. This is what I want. I just really think pd-extended should be assembled, virtually, in package repositories rather than in sourceforge (perhaps with the exception of windows and mac?)
what is important is that pd and its externals build evenly for the multitude of different platforms and that there is no bias towards individual operating systems. this is a balance that hans has very carefully respected with extended, iohannes and co have maintained with gem and what miller generously started with pd.
Agreed. I can't conceive that what I'm advocating would cause problems for Windows and Mac package creation, but maybe I am biased just from ignorance.
and that's why i am working on reshaping the existing build environments to become more modular, in which there is a method for building each lib as a self contained vessel from its own directory (tarball or whatever), while allowing each lib to be tightly woven into any number of custom builders seamlessly.
Sounds great.
i am not so concerned with any particular packaging system, what i am interested in is a simple configurable modular system that builds and installs source into a given tree / jail or whatever you like to call it, in the same manner for each target platform, while also providing useful tools for gathering information and tests for libs, objects and reference material.
Now we're talking.
what package maintainers do to integrate their needs is entirely up to them, but should be done in such a way without touching the behaviour of the overall build mechanism, rather simply extending its functionality through modular scripts and wrappers.
Yes. And I have really been picking apart the current build mechanism in the Gentoo ebuild I have been working on, which is bad, but necessary to make it really modular. I would be happy if I did not need to do this.
anyhow, i have been making steady progress over the previous weeks and i should have a snapshot ready shortly for perusal. if you want to talk directly about my work on the buildsystem i frequent the #dataflow channel of irc.freenode.org along with hans and a number of others. sorry i can't be more explicit with what i am assembling but it's still a bit of shifting target. i also have a dayjob - so this work is divided around scattered freetime so i hope it doesn't seem painfully slow, there'll be something to digest and potentially hack about with soon, so patience is appreciated. my methods may be rubish too, but i have given it a fair bit of consideration, and so too have others, so in this case i think improvement is a better solution than straight up reinvention (but its always exciting to be proved wrong!!).
Awesome. Maybe I'll just shut up until I see what you've got going :)
tim,
yup with you all the way here, i've been chatting a bit to mescalinum about his work with gentoo too, and i'm pretty sure we're all after the same goal.
cheers, dmotd
Tim Jones wrote:
pd-extended could be assembled from parts as a meta package, there's no issue there.
I guess my point is that, if I download the pd-extended tarball, it is not easy at all to assemble it as a series of parts, not as easy and efficient as it could be. At the very least, I think there needs to be some housekeeping done.
as long as a user of extended on windows or osx can run their patch on a debian linux machine without a diminished experience then there should be no concern for how their version of extended was assembled.
Correct! I think Anderson and I are complaining strictly as packagers.
but, while the debian way is good for debian, its not the same fit for other environments. a user of windows doesn't have the same packaging comforts as apt-get and feels far more comfortable with an assembled installer, sure they could pick and choose their parts, but part of the luxury of extended is that its mostly all there and from a new user perspective this makes it instantly more rewarding than a blank canvas with hundreds of unknown installable modules.
All I'm asking for is increased modularity, which is more than just the debian way. Though admittedly I have no idea how Windows installers are built, but I don't think it would be difficult to have a check box or something that says "Install Everything! (Recommended, seriously. Default.)" What I'm really seeking is improvement on modularity for the _build_, not necessarily the package.
but there are alternatives to extended.. planet ccrma has been a very reliable package set for a number of fedora users and i think this may be on a similar tangent to what both anderson and tim are proposing here for debian. similarly pure:dyne maintains their own version of pd, but in a different manner - also worth looking at.
I'll have a look at these. (I'm working on Gentoo :)
i too agree that a monalythic build system does not make sense for long term maintainability, and makes pd as an environment far less configurable for specific needs - but i still support the existence and sustained efforts at packaging pd-extended, it just can be assembled better with greater modularity (making it a template of sorts).
Yesss. This is what I want. I just really think pd-extended should be assembled, virtually, in package repositories rather than in sourceforge (perhaps with the exception of windows and mac?)
what is important is that pd and its externals build evenly for the multitude of different platforms and that there is no bias towards individual operating systems. this is a balance that hans has very carefully respected with extended, iohannes and co have maintained with gem and what miller generously started with pd.
Agreed. I can't conceive that what I'm advocating would cause problems for Windows and Mac package creation, but maybe I am biased just from ignorance.
and that's why i am working on reshaping the existing build environments to become more modular, in which there is a method for building each lib as a self contained vessel from its own directory (tarball or whatever), while allowing each lib to be tightly woven into any number of custom builders seamlessly.
Sounds great.
i am not so concerned with any particular packaging system, what i am interested in is a simple configurable modular system that builds and installs source into a given tree / jail or whatever you like to call it, in the same manner for each target platform, while also providing useful tools for gathering information and tests for libs, objects and reference material.
Now we're talking.
what package maintainers do to integrate their needs is entirely up to them, but should be done in such a way without touching the behaviour of the overall build mechanism, rather simply extending its functionality through modular scripts and wrappers.
Yes. And I have really been picking apart the current build mechanism in the Gentoo ebuild I have been working on, which is bad, but necessary to make it really modular. I would be happy if I did not need to do this.
anyhow, i have been making steady progress over the previous weeks and i should have a snapshot ready shortly for perusal. if you want to talk directly about my work on the buildsystem i frequent the #dataflow channel of irc.freenode.org along with hans and a number of others. sorry i can't be more explicit with what i am assembling but it's still a bit of shifting target. i also have a dayjob - so this work is divided around scattered freetime so i hope it doesn't seem painfully slow, there'll be something to digest and potentially hack about with soon, so patience is appreciated. my methods may be rubish too, but i have given it a fair bit of consideration, and so too have others, so in this case i think improvement is a better solution than straight up reinvention (but its always exciting to be proved wrong!!).
Awesome. Maybe I'll just shut up until I see what you've got going :)
Well,
Too many messages for this morning... later responses will come... i think we are getting closer to a team work.. :D
Just to point out something interesting.. the notes below has a good workflow strategy to deal with packaging on the source. The main idea is create branches with the files from each distribution... i am not experienced with that workflow, but looking it quickly it seems to be a good way to manage our work... maybe one branch for debian/ other for rpm and for gentoo... so the master branch would be always clean! :D
http://www.eyrie.org/~eagle/notes/debian/
ah, a strange problem happened here yesterday. I tried to checkout the svn repository at sourceforge and it couldn't finish... svn occupied all my RAM and swap memory and my computer started do kill process running out of memory.. (which has 4GB). I stopped and run svn up with no success... Any ideas?
bye, global
On Wed, Sep 23, 2009 at 7:42 AM, dmotd inaudible@simplesuperlativ.eswrote:
tim,
yup with you all the way here, i've been chatting a bit to mescalinum about his work with gentoo too, and i'm pretty sure we're all after the same goal.
cheers, dmotd
Tim Jones wrote:
pd-extended could be assembled from parts as a meta package, there's no issue there.
I guess my point is that, if I download the pd-extended tarball, it is not easy at all to assemble it as a series of parts, not as easy and efficient as it could be. At the very least, I think there needs to be some housekeeping done.
as long as a user of extended on windows or osx can run their patch on a debian linux machine without a diminished experience then there should be no concern for how their version of extended was assembled.
Correct! I think Anderson and I are complaining strictly as packagers.
but, while the debian way is good for debian, its not the same fit for other environments. a user of windows doesn't have the same packaging comforts as apt-get and feels far more comfortable with an assembled installer, sure they could pick and choose their parts, but part of the luxury of extended is that its mostly all there and from a new user perspective this makes it instantly more rewarding than a blank canvas with hundreds of unknown installable modules.
All I'm asking for is increased modularity, which is more than just the debian way. Though admittedly I have no idea how Windows installers are built, but I don't think it would be difficult to have a check box or something that says "Install Everything! (Recommended, seriously. Default.)" What I'm really seeking is improvement on modularity for the _build_, not necessarily the package.
but there are alternatives to extended.. planet ccrma has been a very reliable package set for a number of fedora users and i think this may be on a similar tangent to what both anderson and tim are proposing here for debian. similarly pure:dyne maintains their own version of pd, but in a different manner - also worth looking at.
I'll have a look at these. (I'm working on Gentoo :)
i too agree that a monalythic build system does not make sense for long term maintainability, and makes pd as an environment far less configurable for specific needs - but i still support the existence and sustained efforts at packaging pd-extended, it just can be assembled better with greater modularity (making it a template of sorts).
Yesss. This is what I want. I just really think pd-extended should be assembled, virtually, in package repositories rather than in sourceforge (perhaps with the exception of windows and mac?)
what is important is that pd and its externals build evenly for the multitude of different platforms and that there is no bias towards individual operating systems. this is a balance that hans has very carefully respected with extended, iohannes and co have maintained with gem and what miller generously started with pd.
Agreed. I can't conceive that what I'm advocating would cause problems for Windows and Mac package creation, but maybe I am biased just from ignorance.
and that's why i am working on reshaping the existing build environments to become more modular, in which there is a method for building each lib as a self contained vessel from its own directory (tarball or whatever), while allowing each lib to be tightly woven into any number of custom builders seamlessly.
Sounds great.
i am not so concerned with any particular packaging system, what i am interested in is a simple configurable modular system that builds and installs source into a given tree / jail or whatever you like to call it, in the same manner for each target platform, while also providing useful tools for gathering information and tests for libs, objects and reference material.
Now we're talking.
what package maintainers do to integrate their needs is entirely up to them, but should be done in such a way without touching the behaviour of the overall build mechanism, rather simply extending its functionality through modular scripts and wrappers.
Yes. And I have really been picking apart the current build mechanism in the Gentoo ebuild I have been working on, which is bad, but necessary to make it really modular. I would be happy if I did not need to do this.
anyhow, i have been making steady progress over the previous weeks and i should have a snapshot ready shortly for perusal. if you want to talk directly about my work on the buildsystem i frequent the #dataflow channel of irc.freenode.org along with hans and a number of others. sorry i can't be more explicit with what i am assembling but it's still a bit of shifting target. i also have a dayjob - so this work is divided around scattered freetime so i hope it doesn't seem painfully slow, there'll be something to digest and potentially hack about with soon, so patience is appreciated. my methods may be rubish too, but i have given it a fair bit of consideration, and so too have others, so in this case i think improvement is a better solution than straight up reinvention (but its always exciting to be proved wrong!!).
Awesome. Maybe I'll just shut up until I see what you've got going :)
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev