On Dec 7, 2005, at 12:18 PM, ix wrote:
Now that I have the new build system working smoothly, I'd like to start removing files from externals/build/src, as the are put into
someone spent a lot of time adding all those "#include ../../this/that.c" files..are you suggesting to undo this entirely?
Those people in question were mostly Guenter and I (out of 943 commits to externals/build/src, I did 441, Guenter did 369). So yes, I am willing to undo my own work and I hope Guenter will agree. This system has worked well for us for a while, thanks to Guenter for building the foundation. But now there is something better.
I am not suggesting just deleting everything now, but just removing things as they are incorporated into externals/Makefile. Its especially important to remove objects with name conflicts from the root of extra. If, for example, [prepend] is directly in extra, then you won't be able to load a lib to use another [prepend]. Pd will always find the [prepend] in the root dir first.
The idea is to have externals/Makefile build the code right in place in the directory where its stored. Then each developer doesn't need to maintain their own build system. This is now done now for cxc, cyclone, ext13, freeverb~, motex, pddp, smlib, toxy, unauthorized, zexy. So there is no longer a need to create the "#include ../../this/that.c" link files, except for when the more than one file needs to be compiled into one object.
i guess my main question would be, am i now going to have to update the SConscript to check 50 directories instead of one after your changes. if thats the case i vote for leaving it how it is..
Again, I don't see any benefit to maintaining two separate build systems for the same thing, especially if it creates extra work for others who don't use the second build system. I have no problem if you want to use scons, I am sure scons can call "make install". Then scons can use the existing Makefiles and we won't be duplicating efforts.
If you want to have everything in one directory, you can easily do this: "find ~/build/extra -name '*.pd_linux' | xargs -J % cp % ~/build". Its much more work to go the other way once things are compiled and installed into one directory. Then you have to keep a list of what files go where. This list already exists in the form of the directories in "externals", so if the files are built in place, then its obvious where they came from so this structure makes sense on that level too.
.hc
externals/Makefile with their own specific Makefile targets. I am not suggesting removing any from the distros, just reorganizing things into individual libdirs so that the namespace works.
i'm not sure what you mean by the 'namespace works'. is this the '[cc/prepend]' type thing? if so, that can be handled at install time for those that want it..
Any objections?
.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
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
________________________________________________________________________ ____
"The arc of history bends towards justice." - Dr. Martin Luther King, Jr.