On Jul 1, 2010, at 12:33 PM, dmotd wrote:
hi hans,
okay, i still have no real idea what you are talking about here? i get the makefile template, but how exactly does this relate to a buildsystem, the examples that use the template are still called by the centralised makefile?
yes, check ext13 externals/Makefile for example.
thomas maintains his own buildsystem and as much as its apparently stumped a bunch of people in the past, it is designed for cross platform AND max/msp. to redesign an entire build system to fit a template, for sake of maintaining some design rules seems a little over the top, that's why i decided to simply wrap it. besides, the flext layer has enough complexity to require a decent autoconf first, and if recent threads are correct, there's no libdir based autoconf template.
A libdir autoconf template would be awesome to have though. Building C or C++ objects for Pd isn't hard. What about flext makes things so complicated? In the process of making that template Makefile, I realized that autotools is really rarely needed for externals. Only really when there are a lot of library dependencies.
the thing that has me confused is this notion of packaging? if pd-X is going to disolve into a system of separated libs (libdirs?) called by a virtual package 'pd-X', and thus 'debianize' the entire system, then i support that - however there must be some wrapper script that does the job that pd-X currently does? i understand that the template is designed to make that job simpler, by making the build assumptions the responsibility of each lib and creating a libdir path, but how does this actually spawn packages?
what i like about pd-X is that it unifies a lot of extras and provides a neat wrapper for the build, so i'm assuming that your direction will be providing scripts to wrap certain build environments (osx/win/fed/deb/ubu/etc). have you got examples of how this next generation of build scripts will look with the makefile-template, or will the current centralised system slowly morph into the desired endpoint? i am a little concerned that a 'one size fits all' may not fit all...
The core idea is to avoid one-size-fits-all by decentralizing the libraries. If libraries are really easy to make, distribute and install, then there isn't a strong need to have all the libraries included in Pd-extended itself. People can maintain their libraries entirely separately, removing the unavoidable roadblocks that happen when things get centralized.
For Pd-extended 0.43, I think we should be removing a bunch of libraries that are not really used or maintained and make them separately distributed. You can see some idea of the plans here:
http://puredata.info/dev/NextRelease
That said, there is value to having a default set of libraries that you know will always be included with Pd-extended. I think to get to that point, libraries need to be very stable both in terms of their interface/features and their bugginess. Think of python libraries, or ruby, etc.
.hc
anyway, without some guidelines, i'm not sure i will ever understand what you have in mind, and what is acceptable practice. i'm just wanting to contribute something that's been missing from the pd-x object pool, without getting too caught up in some fundamental change of practice.
best, dmotd
Hans-Christoph Steiner wrote:
The idea is to have all libraries have their own standalone build systems that do not rely on the packages/Makefile.buildlayout stuff. That's the idea with the Makefile/library template.
I think the best plan for flext would be to make a version of the template Makefile that works for C++/flext. Then that Makefile can easily be used for Debian/Ubuntu/RPM/etc. packaging.
http://puredata.info/docs/developer/MakefileTemplate
I could see including the flext library itself in Pd-extended, that is if it is not changing much. But the externals itself should start out separately distributed libdirs IMHO.
.hc
On Jun 28, 2010, at 9:50 PM, dmotd wrote:
hi hans,
the work i've done slots straight into the existing externals/Makefile structure and currently builds fine on linux, it uses thomas' build system and until a better autoconf alternative is created, this is by far the easiest (and has been working quite well for years). as such this a multi-class single lib system.
i have followed the libdir rules, with help-files abstraction (and in py/ext case scriptets) in each libs own dir, and other stuff in examples. the actual flext headers and libs get installed in their own $prefix/include $prefix/lib.
my intention is to get the flext externals into the nightly autobuid. i'm not sure what you mean by 'distribuited as stand-alone', if this is a reference to your plan to split supported pd-extended libs into individual packages, then i'll need to know more about what scripts you have at your disposal and your release schedule for this new packaging system.
i've attached a diff of my working makefile, which will need to be tested against other platforms and linux distributions. currently the following libs build and install correctly: absattr, pool, py, xsample (i am waitinng on some fixes up stream for clk and vasp)
sorry for not emailing earlier, i've had little time to work on this stuff and just ran with the momentum with the small time i have had.
cheers, dmotd
Hans-Christoph Steiner wrote:
Hey, I just saw you are working flext stuff, lots of people will appreciate that. I don't know your plan, but I wanted to save you some effort. At this point, I think that the flext stuff should be distributed as standalone libraries, rather than integrated with Pd- extended. That makes it easier to package too, for things like archlinux, Debian, Fedora, etc.
Also, if you are starting in on packaging things for archlinux, check out the externals/template. If you can make a template archlinux packaging file for that, then it'll be really easy to make packages for all of the libraries that use that template:
http://puredata.info/docs/developer/MakefileTemplate
.hc
News is what people want to keep hidden and everything else is publicity. - Bill Moyers
<flext.diff>
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
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
----------------------------------------------------------------------------
Information wants to be free. -Stewart Brand