hi
i've done a little work on the SConscript in external build system to better support osx: - define MACOSX for osx builds (for miXed) - remove -dynamiclib from SHLINKFLAGS and add -bundle and - bundle_loader ../../pd/bin/pd - fink and darwinports locations are added to CPPPATH and LIBPATH if they exist - search for *.libs files in win/darwin/linux and after in src directory and add the flags
- some few externals still don't compile because of missing libraries and .libs or minor include problems.
perhaps we could introduce some static link option (i'm not sure if i'd like statically linked externals). another possibility would be to just grep for the used libraries (*.libs) and bundle them with the externals or with pd.app (not quite trivial. see: http://qin.laya.com/ tech_coding_help/dylib_linking.html).
lorenz
Its unfortunate that we have two build systems that do the exact same thing. It would be nice if all that effort went into one build system that was really good, instead of making a new one that duplicates the old one. This is all stuff that was covered years ago in the makefiles.
But I guess that's open source. People are welcome to do whatever floats their boat. I am certainly not going to stop anyone.
.hc
On Oct 28, 2005, at 9:09 AM, Lorenz Schori wrote:
hi
i've done a little work on the SConscript in external build system to better support osx:
- define MACOSX for osx builds (for miXed)
- remove -dynamiclib from SHLINKFLAGS and add -bundle and
-bundle_loader ../../pd/bin/pd
- fink and darwinports locations are added to CPPPATH and LIBPATH if
they exist
- search for *.libs files in win/darwin/linux and after in src
directory and add the flags
- some few externals still don't compile because of missing libraries
and .libs or minor include problems.
perhaps we could introduce some static link option (i'm not sure if i'd like statically linked externals). another possibility would be to just grep for the used libraries (*.libs) and bundle them with the externals or with pd.app (not quite trivial. see: http://qin.laya.com/tech_coding_help/dylib_linking.html).
lorenz
<SConstruct>
________________________________________________________________________ ____
Using ReBirth is like trying to play an 808 with a long stick.
-David Zicarelli
On Mon, Oct 31, 2005 at 08:05:01PM -0500, Hans-Christoph Steiner wrote:
Its unfortunate that we have two build systems that do the exact same thing.
not true..the 'make' script builds single C sources which have been aliased into the build/src/ dir, the SCons script builds those as well as various libraries that i liked. theres no extra work to support both if you put the files in build/src..
some systems have python and not autotools, and vice versa..
It would be nice if all that effort went into one build system that was really good, instead of making a new one that duplicates the old one.
not true if by 'old one' you mean /externals/build/{platform} (3 seperate systems) - but it is duplicating/replacing build scripts of individual libraries, which could get out of synch over time...somehow SConscripts seemed more robust than scripting a 'make' via exec()..but given gentoo's very successful approach in doing that, it could be considered..
but really, read the cyclone makefile and tell me you know what its doing! i had to rewrite it in SCons just to figure out how everything fit together..
This is all stuff that was covered years ago in the makefiles.
could you type 'make' once and get zexy, cyclone, pdcontainer, ann, pmpd, unauthorized, OSCx, etc? i dont think you could..
But I guess that's open source. People are welcome to do whatever floats their boat. I am certainly not going to stop anyone.
me neither :) feel free to add iemlib or anything else you think is missing..an ebuild to grab all the dependencies would be nice as well..
c
.hc
On Oct 28, 2005, at 9:09 AM, Lorenz Schori wrote:
hi
i've done a little work on the SConscript in external build system to better support osx:
- define MACOSX for osx builds (for miXed)
- remove -dynamiclib from SHLINKFLAGS and add -bundle and
-bundle_loader ../../pd/bin/pd
- fink and darwinports locations are added to CPPPATH and LIBPATH if
they exist
- search for *.libs files in win/darwin/linux and after in src
directory and add the flags
- some few externals still don't compile because of missing libraries
and .libs or minor include problems.
perhaps we could introduce some static link option (i'm not sure if i'd like statically linked externals). another possibility would be to just grep for the used libraries (*.libs) and bundle them with the externals or with pd.app (not quite trivial. see: http://qin.laya.com/tech_coding_help/dylib_linking.html).
lorenz
<SConstruct>
Using ReBirth is like trying to play an 808 with a long stick.
-David Zicarelli
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
On Oct 31, 2005, at 11:18 PM, carmen wrote:
On Mon, Oct 31, 2005 at 08:05:01PM -0500, Hans-Christoph Steiner wrote:
Its unfortunate that we have two build systems that do the exact same thing.
not true..the 'make' script builds single C sources which have been aliased into the build/src/ dir, the SCons script builds those as well as various libraries that i liked. theres no extra work to support both if you put the files in build/src..
Well, that has nothing to do with scons or make, its a design decision. Any build system could do both single files, libs, or both.
some systems have python and not autotools, and vice versa..
But generally, any system can have either installed, thanks to them being free software.
It would be nice if all that effort went into one build system that was really good, instead of making a new one that duplicates the old one.
not true if by 'old one' you mean /externals/build/{platform} (3 seperate systems) - but it is duplicating/replacing build scripts of individual libraries, which could get out of synch over time...somehow SConscripts seemed more robust than scripting a 'make' via exec()..but given gentoo's very successful approach in doing that, it could be considered..
The libraries should be deprecated where ever possible, instead we should use a common build system. That will save everyone a lot of time. The one in externals/build works well, no its not perfect, but its there and it works.
but really, read the cyclone makefile and tell me you know what its doing! i had to rewrite it in SCons just to figure out how everything fit together..
But you don't need to understand it if it works, just use it. I certainly don't understand everyone's build system. SConscript makes even less sense to me since I have little experience with it, but I am sure I could call it from a Makefile if someone gave me the command line. But I am not interested in whether make or scons is better. What is in place works. If it ain't broke, don't fix it.
This is all stuff that was covered years ago in the makefiles.
could you type 'make' once and get zexy, cyclone, pdcontainer, ann, pmpd, unauthorized, OSCx, etc? i dont think you could..
You should try the Pd.app build system (packages/darwin_app/Makefile). You type 'make' once and you get Pd, externals, comport, iemlib, ggee, hid, pmpd, unauthorized, cyclone, OSCx, Gem, PDDP, RRADical, maxlib, flext, docs/tutorials/abstractions from CVS, toxy, etc. Any now Jamie just added PDP, pdp2gem and pix_2pdp to that too. It would be great to also have PdContainer and ann to that as well. But instead we have a second build system that doesn't do as much.
Anyway, I'll be working on porting the Pd.app build system to Windows and Linux this month, so then we'll have a unified build on all three platforms. I'd love any help, the build system so far has been very much a group effort, and more we join forces, the better it'll get.
.hc
But I guess that's open source. People are welcome to do whatever floats their boat. I am certainly not going to stop anyone.
me neither :) feel free to add iemlib or anything else you think is missing..an ebuild to grab all the dependencies would be nice as well..
c
.hc
On Oct 28, 2005, at 9:09 AM, Lorenz Schori wrote:
hi
i've done a little work on the SConscript in external build system to better support osx:
- define MACOSX for osx builds (for miXed)
- remove -dynamiclib from SHLINKFLAGS and add -bundle and
-bundle_loader ../../pd/bin/pd
- fink and darwinports locations are added to CPPPATH and LIBPATH if
they exist
- search for *.libs files in win/darwin/linux and after in src
directory and add the flags
- some few externals still don't compile because of missing libraries
and .libs or minor include problems.
perhaps we could introduce some static link option (i'm not sure if i'd like statically linked externals). another possibility would be to just grep for the used libraries (*.libs) and bundle them with the externals or with pd.app (not quite trivial. see: http://qin.laya.com/tech_coding_help/dylib_linking.html).
lorenz
<SConstruct>
__ ____
Using ReBirth is like trying to play an 808 with a long stick.
-David Zicarelli
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
________________________________________________________________________ ____
"[W]e have invented the technology to eliminate scarcity, but we are deliberately throwing it away to benefit those who profit from scarcity."
-John Gilmore
On Nov 1, 2005, at 2:38 AM, Georg Holzmann wrote:
Hallo!
just added PDP, pdp2gem and pix_2pdp to that too. It would be great to also have PdContainer and ann to that as well. But instead we have a
hm - I will have a look at it ...
Great! Please do not hesitate to ask any questions. Just post them here, and I'll respond. I'll be working on this stuff over the next month anyhow.
It needs to be documented better, so your questions will push me to do so.
.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
The libraries should be deprecated where ever possible, instead we should use a common build system. That will save everyone a lot of time.
why?
The one in externals/build works well, no its not perfect, but its there and it works.
the problem is, it's only working well for a subset of externals. iirc, there is not a single flext external in there.
btw, i'm using scons as extension to the flext build system, which works pretty reliable since it's easy to extend it to non-standard cases. (searching for weird libraries etc) imo, someone should look into it and write a platform independent scons Builder then we wouldn't have this nasty discussion any more.
t
On Tue, 1 Nov 2005, Tim Blechmann wrote:
The libraries should be deprecated where ever possible, instead we should use a common build system. That will save everyone a lot of time.
why?
And furthermore, how are libraries excluding the possibility of a common build system, and how do cutting libraries into separate externals has to do with a common build system, and also how does Pd or anyone else distinguish "libraries" and "externals" (because AFAIK they _don't_) ?
____________________________________________________________________ Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju Freelance Digital Arts Engineer, Montréal QC Canada
Hallo, Tim Blechmann hat gesagt: // Tim Blechmann wrote:
imo, someone should look into it and write a platform independent scons Builder then we wouldn't have this nasty discussion any more.
Trying to get the discussion back from nasty and on to some more technical stuff: Without any offence intended I don't think the traditional build system was working perfecly well, and in some regards it ways really hitting at walls. It is great for what it tried to be great at, that is, building single externals, which are not using (many) libraries and which are written in C. It has problems with externals using several source files or externals written in C++ in certain areas.
Others (carmen etc.) also thought the "build" was limited and as action speaks louder, they just made a new one without breaking the old one. That's fine. (Btw: There also is the flext-buildsys, a third try to get over all the difficulties with building stuff for different platforms.)
We could discuss (again) if libraries are good or bad, however even scons tries to build as much as possible as single externals (e.g. it builds Zexy that way). Scons however makes it easier to also get libraries into the build and as Tim noted it also can be used to build C++/flext externals like PDContainer or pool.
What I think is impressive about scons, is that it doesn't require that much work to get new externals into the build system. It is not strictly necessary to #include-link files into "build", instead also a "SConscript" in (selected) source directories can be used.
I don't like at all, that the main SConscript deletes stuff from build locally and that it does so using platform dependent sh instructions. That's not the way a build system in CVS should work. Maybe it would be possible to find a cleaner solution to conflicting externals.
Also the way it is set up should be better documented than just "scons; scons install". Things like how to set an install prefix should be explained as well as how to add new externals to the scons build. This is an area, where the traditional build is much better.
However I do think, that scons could actually be the more flexible solution to get all the different build preferences of every developer together. So I'd like it if we could discuss this openly.
Ciao
On Nov 1, 2005, at 6:45 AM, Frank Barknecht wrote:
Hallo, Tim Blechmann hat gesagt: // Tim Blechmann wrote:
imo, someone should look into it and write a platform independent scons Builder then we wouldn't have this nasty discussion any more.
Trying to get the discussion back from nasty and on to some more technical stuff: Without any offence intended I don't think the traditional build system was working perfecly well, and in some regards it ways really hitting at walls. It is great for what it tried to be great at, that is, building single externals, which are not using (many) libraries and which are written in C. It has problems with externals using several source files or externals written in C++ in certain areas.
First off, I had no intention of being nasty, or a desire to be. I am sorry if I came across that way. I just get depressed that our limited dev resources are spent reinventing the wheel. The externals/build system isn't perfect, but that doesn't mean it can't be made better without being totally discarded. But it does work well, and on all platforms with standard tools that basically all developers use and know enough about.
And yes, there should be a separate C++ build system. And there is with flext.
Others (carmen etc.) also thought the "build" was limited and as action speaks louder, they just made a new one without breaking the old one. That's fine. (Btw: There also is the flext-buildsys, a third try to get over all the difficulties with building stuff for different platforms.)
It just takes some communication, then we can work together. Or we could go back to the pre-CVS days where everyone just wrote their own stuff totally separately, and if you wanted to use it, you had to figure out a each person's build system, deps, etc.
We could discuss (again) if libraries are good or bad, however even scons tries to build as much as possible as single externals (e.g. it builds Zexy that way). Scons however makes it easier to also get libraries into the build and as Tim noted it also can be used to build C++/flext externals like PDContainer or pool.
externals/build already builds zexy as single externals. packages/darwin_app/Makefile builds libs as well, like pmpd. Most of what's in packages/darwin_app/Makefile is just basic makefile stuff, so it will be an easy port to Linux and MinGW/Windows.
What I think is impressive about scons, is that it doesn't require that much work to get new externals into the build system. It is not strictly necessary to #include-link files into "build", instead also a "SConscript" in (selected) source directories can be used.
I don't like at all, that the main SConscript deletes stuff from build locally and that it does so using platform dependent sh instructions. That's not the way a build system in CVS should work. Maybe it would be possible to find a cleaner solution to conflicting externals.
Also the way it is set up should be better documented than just "scons; scons install". Things like how to set an install prefix should be explained as well as how to add new externals to the scons build. This is an area, where the traditional build is much better.
Its quite simple to add a new C external to externals/build, usually it consists only of adding the .c link file to externals/build/src and the documentation files to externals/build/doc/makefile. Check out externals/build/README for documentation on how to add yours.
Adding new externals, abstractions, libs, docs, tutorials, etc. to packages/darwin_app/Makefile is also relatively easy, you basically just add the command lines that you would type to compile and install that set of externals. It does need better documentation, but there is some already.
I haven't really used flext, so I can't speak to that.
However I do think, that scons could actually be the more flexible solution to get all the different build preferences of every developer together. So I'd like it if we could discuss this openly.
Like I said, I am not going to stop anyone. But its just a shame that work is going into a new build system that is just duplicating existing functionality. Instead, if that same amount of effort had been put into the existing system, then we'd have a much better system than either of the ones that exist now.
make isn't perfect, but its something that basically all C developers know enough about. Personally, I've never used python, so its much less attractive to me. The last thing I want to do spend time learning yet another build system when the current one works.
.hc
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
________________________________________________________________________ ____
If you are not part of the solution, you are part of the problem.
- Eldridge Cleaver
But its just a shame that work is going into a new build system that is just duplicating existing functionality...the system isn't perfect, but that doesn't mean it can't be made better without being totally discarded.
but thats what youre doing right? is /packages/darwin_app/Makefile not another 'build system'?
this makes 3..one more, and pd can hit the road! vroom vroom!
And yes, there should be a separate C++ build system.
other places you are suggesting to unify them, yet here you are saying we should have seperate systems? that can't be..since C++ and C have happily coexisted for years in all of the 'make' and make-replacements i can think of ...
what's in packages/darwin_app/Makefile is just basic makefile stuff, so it will be an easy port to Linux and MinGW/Windows.
considering build system #1 (make) and #2 (SCons) already run on various platforms, and #3 like #1 is also using 'make', this should be no problem. but maybe instead of having /packages/platform and /externals/build and /externals/build/platform we should just have a /build, and there should be options for 'just core' 'just externals' 'everything', etc...
On Nov 1, 2005, at 12:04 PM, carmen wrote:
But its just a shame that work is going into a new build system that is just duplicating existing functionality...the system isn't perfect, but that doesn't mean it can't be made better without being totally discarded.
but thats what youre doing right? is /packages/darwin_app/Makefile not another 'build system'?
this makes 3..one more, and pd can hit the road! vroom vroom!
packages/darwin_app/Makefile is a unified build system, it just calls other existing builds, like externals/build/darwin/makefile, externals/grill/flext, externals/miXed/, etc. etc. Its been around for 2+ years.
And yes, there should be a separate C++ build system.
other places you are suggesting to unify them, yet here you are saying we should have seperate systems? that can't be..since C++ and C have happily coexisted for years in all of the 'make' and make-replacements i can think of ...
what's in packages/darwin_app/Makefile is just basic makefile stuff, so it will be an easy port to Linux and MinGW/Windows.
considering build system #1 (make) and #2 (SCons) already run on various platforms, and #3 like #1 is also using 'make', this should be no problem. but maybe instead of having /packages/platform and /externals/build and /externals/build/platform we should just have a /build, and there should be options for 'just core' 'just externals' 'everything', etc...
Exactly, that's what packages/darwin_app/Makefile is! Check it out! Soon it shall be multi-platform too, thanks to some sponsorship.
.hc ________________________________________________________________________ ____
"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
another one throwing oil on the fire...
Hans-Christoph Steiner wrote:
We could discuss (again) if libraries are good or bad, however even scons tries to build as much as possible as single externals (e.g. it builds Zexy that way). Scons however makes it easier to also get libraries into the build and as Tim noted it also can be used to build C++/flext externals like PDContainer or pool.
externals/build already builds zexy as single externals. packages/darwin_app/Makefile builds libs as well, like pmpd. Most of what's in packages/darwin_app/Makefile is just basic makefile stuff, so it will be an easy port to Linux and MinGW/Windows.
i just want to note, that when building zexy as separate externals instead of one big library you are _not_ getting all the functionality.
i am sorry for that but it cannot be helped: the problem is as simple as finding an alphanumeric name for the setup-function of [>~]. (yes there are abstractions for [>~], but there are serious problems on some platforms with forbidden characters like ">"; and the abstractions are less high-performance than the externals are/would be; and they have slightly different behaviour!)
i once addressed thes problems (solutions should be simple enough), but since nobody answered that mail, i guess it is of no importance.
mfg.adsr. IOhannes
On Nov 1, 2005, at 6:42 AM, Tim Blechmann wrote:
The libraries should be deprecated where ever possible, instead we should use a common build system. That will save everyone a lot of time.
why?
This has been discussed ad nauseum. Here's two reasons: 1) look at how many people post to the list with questions about loading libs, how many people post with problems loading single file externals? 2) ever had trouble with namespace conflicts? Try solving that when you are using libs. Sometimes its not possible.
The one in externals/build works well, no its not perfect, but its there and it works.
the problem is, it's only working well for a subset of externals. iirc, there is not a single flext external in there.
btw, i'm using scons as extension to the flext build system, which works pretty reliable since it's easy to extend it to non-standard cases. (searching for weird libraries etc) imo, someone should look into it and write a platform independent scons Builder then we wouldn't have this nasty discussion any more.
Flext externals are now included in the Pd.app build system (packages/darwin_app/Makefile). I'll be porting this to Linux and Windows, so we can have unified builds on all platforms. externals/build only works for C-based Pd externals, as it should. Flext has it own unified build system.
.hc
t
-- mailto:TimBlechmann@gmx.de ICQ: 96771783 http://www.mokabar.tk
latest mp3: kMW.mp3 http://mattin.org/mp3.html
latest cd: Goh Lee Kwang & Tim Blechmann: Drone http://www.geocities.com/gohleekwangtimblechmannduo/
After one look at this planet any visitor from outer space would say "I want to see the manager." William S. Burroughs
________________________________________________________________________ ____
¡El pueblo unido jamás será vencido!
This has been discussed ad nauseum. Here's two reasons: 1) look at how many people post to the list with questions about loading libs, how many people post with problems loading single file externals?
there are different ways to handle this ... e.g. a proper #include, import, site-lisp, site-packages, site_perl (i know, this would require changes to the language pd)
ever had trouble with namespace conflicts? Try solving that when you are using libs. Sometimes its not possible.
if i have a zexy.pd_linux and a cyclone.pd_linux, i know, which sources i have, if i have a "prepend.pd_linux" and a "prepend.pd_linux" i have no idea, which prepend i have. splitting libs to externals doesn't really help to solve this problem, it just changes the responsibility from the developer to the user. but it's not helping anything! i think, the only way to solve the name clashes is _communication_ and the ambition to resolve them. but that's a community issue.
t
On Nov 1, 2005, at 1:34 PM, Tim Blechmann wrote:
This has been discussed ad nauseum. Here's two reasons: 1) look at how many people post to the list with questions about loading libs, how many people post with problems loading single file externals?
there are different ways to handle this ... e.g. a proper #include, import, site-lisp, site-packages, site_perl (i know, this would require changes to the language pd)
ever had trouble with namespace conflicts? Try solving that when you are using libs. Sometimes its not possible.
if i have a zexy.pd_linux and a cyclone.pd_linux, i know, which sources i have, if i have a "prepend.pd_linux" and a "prepend.pd_linux" i have no idea, which prepend i have. splitting libs to externals doesn't really help to solve this problem, it just changes the responsibility from the developer to the user. but it's not helping anything!
Actually, splitting libs into externals and using the geiger namespace DOES solve this problem. You can individually select the object that you want but using [cyclone/prepend], [iemlib/prepend], etc. Yes, there are problems with this, like you won't get the right help file unless we change the C code, but its much better than the old problems with libs.
This is something that has been on my TODO list for a long while, maybe I'll do this for the upcoming multi-platform release.
i think, the only way to solve the name clashes is _communication_ and the ambition to resolve them. but that's a community issue.
Communication is good on the small scale, but as the developer community grows, then it becomes a waste of time because all the chatter on the list will be about this topic. The real solution is a proper namespace, like Java has with its imports, and this can be done using the geiger namespace and a [declare] object and some other minor things.
.hc
________________________________________________________________________ ____
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
Communication is good on the small scale, but as the developer community grows, then it becomes a waste of time because all the chatter on the list will be about this topic. The real solution is a proper namespace, like Java has with its imports, and this can be done using the geiger namespace and a [declare] object and some other minor things.
this is on my todo list ... but i'm not sure, if this will ever make it into pd
t
-
carmen -
Frank Barknecht -
Georg Holzmann -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
Lorenz Schori -
Mathieu Bouchard -
Tim Blechmann