Patches item #1842833, was opened at 2007-12-02 12:35 Message generated for change (Comment added) made by russellbryant You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1842833...
Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: externals Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Russell Bryant (russellbryant) Assigned to: Nobody/Anonymous (nobody) Summary: ggee/makefile.sub cleanup and documentation
Initial Comment: I went looking around through externals. Specifically, I was interested in looking at [streamin~]/[streamout~]. I was also interested in how the externals were being built.
So, while looking at how these externals were built, I made some significant changes to this Makefile.
Changes:
ggee/signal/Makefile:
- Simply add the -f option to rm to avoid errors being sent to the console when files don't exist to get removed.
ggee/makefile.sub:
- Added comments to sections of the Makefile to describe what they are for
- Centralized the handling of CFLAGS and LDFLAGS to one spot so it is clear what is platform specific.
- Re-work the compilation and linking targets so that they use the new handling of the CFLAGS and LDFLAGS.
----------------------------------------------------------------------
Comment By: Russell Bryant (russellbryant)
Date: 2007-12-04 16:32
Message: Logged In: YES user_id=1942915 Originator: YES
That's fine. Feel free to close this out. However, if the Makefile isn't really used, maybe it could just be removed. :)
In fact, I much prefer a centralized common build system. You say that it needs work. I don't mind helping out with that a bit, as I have (for better or worse) had a decent amount of experience with gnu make and autoconf.
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave) Date: 2007-12-04 16:17
Message: Logged In: YES user_id=27104 Originator: NO
That makefile isn't used much any more. Most of the time, things are built using the centralized Makefile in externals/Makefile. This centralized thing isn't the best system, it definitely needs work, but it works for the most part.
----------------------------------------------------------------------
You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1842833...
Hey,
I thought I'd move this to the pd-dev list since it allows for easier discussion.
We could definitely use some help with autoconf/make stuff. Basically, there has been some talk about making an unified autoconf build system for the "externals" section for a while. This section is maintained directly in CVS, so it's easy to work on.
The core "pd/src" section could probably use some help with the autoconf stuff, but that is maintained in Miller's private git and the patch tracker, so that would be much more work to work on. Also, we'll have to hear from Miller to see if he is interested in any major improvements there.
Right now, in the 'externals' section, there are many build systems for different sections that reflect the build systems that the given dev used before importing the code into CVS. A couple of these use their own private autoconf setups (pdstring, pdp, pidip, zexy, OSCx, and probably others). I personally think that there should be one central autoconf system for everything.
For any of the code that I am responsible for (hcs, mapping, tkwidgets, smlib) I am completely open to changes. Other sections having varying statuses, like some are imports from other repositories (like pdp) so it is probably best to leave those as is. I think the best plan would be for you to layout the structure of the autoconf and recursive makefiles, then the gaps can be filled in following by example.
.hc
Comment By: Russell Bryant (russellbryant)
Date: 2007-12-04 16:32
Message: Logged In: YES user_id=1942915 Originator: YES
That's fine. Feel free to close this out. However, if the Makefile isn't really used, maybe it could just be removed. :)
In fact, I much prefer a centralized common build system. You say that it needs work. I don't mind helping out with that a bit, as I have (for better or worse) had a decent amount of experience with gnu make and autoconf.
Comment By: Hans-Christoph Steiner (eighthave) Date: 2007-12-04 16:17
Message: Logged In: YES user_id=27104 Originator: NO
That makefile isn't used much any more. Most of the time, things are built using the centralized Makefile in externals/Makefile. This centralized thing isn't the best system, it definitely needs work, but it works for the most part.
You can respond by visiting: https://sourceforge.net/tracker/? func=detail&atid=478072&aid=1842833&group_id=55736
------------------------------------------------------------------------ ----
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:
Hey,
Right now, in the 'externals' section, there are many build systems for different sections that reflect the build systems that the given dev used before importing the code into CVS. A couple of these use their own private autoconf setups (pdstring, pdp, pidip, zexy, OSCx, and probably others). I personally think that there should be one central autoconf system for everything.
my personal problem with this (as explained at length before), is that i desperately want an external to be self-contained (apart from obvious dependencies like the pd-headers).
for me this implies the build-system to be modular and not depend on a an up-level configuration. e.g. if i want to build "aconnect" external that lives in externals/iem/aconnect/ then i do not want to have to checkout externals/Makefile and what else and depend on a deep directory structure. it should be enough to get externals/iem/aconnect/ and be able to compile the external (without having to know all the compiler and linker flags by heart)
i think this is really essential for my use of the externals.
having said all that, this doesn't mean that i think it a bad idea to provide information in a centralized manner. the key point however is that the information should be provided to be pulled from a certain external's build-system rather than pushed to it.
what i mean by this is: each external should have a self-contained build-system that is able to build the external without any up-level dependencies. however, this build-system should respect environmental variables that are set by an up-stream configuration process, and which is therefore able to guarantee that all externals are actually configured the same way.
i don't know yet, how we could handle this generically for a master include-file. (config.h)
btw, before the pd-convention i have setup a wiki to discuss exactly this issues http://puredata.info/Members/zmoelnig/pdcon07/BuildIntegration/
mfg.asdr IOhannes
-
Hans-Christoph Steiner -
IOhannes m zmoelnig -
SourceForge.net