That's the vague idea of the current makefiles there. But since many
people didn't want to change the existing makefiles within each
library folder, almost everything is stuck into externals/Makefile.
I think if someone came up with a better system, then there wouldn't
be objections to replacing the makefiles within each lib directory.
Ideally, it should follow all of the GNU standards, like using
'prefix', DESTDIR, etc.
.hc
On Oct 15, 2008, at 11:42 AM, Alex wrote:
I'm willing to work on the externals. I'm rather busy at the moment but am willing to slowly work on writing makefiles for various externals that need their own. I figure we should start with some generic makefile that maybe tests for environment variables for the INSTALL_PREFIX, location of m_pd.h, .. what else..? so that it could be called from a higher up makefile with that info setup already.
-Alex
On Mon, Oct 13, 2008 at 4:20 AM, IOhannes m zmoelnig
zmoelnig@iem.at wrote:carmen r wrote:
'externals' cannot be self-sufficient since it will always
depend on the headers in 'pd'.the existing scripts were smart enough to find m_pd.h (and the
other headers) alonside externals/, or its parent directorysee miXed/ it still works that way
the issue is you introduced dependencies on several new toplevel
dirs for no good reasonand broke up the modularity of the makefiles
this has basically been my arguing for ages.
i would very much like to revamp the entire build-system, but haven't had the time to do it. if several people are interested in doing so we could form a
taskforce and just do it.oh well, unsubscribing. have fun in your broken paradise
oh well, your zeal was shortlived then.... let me know if you are still interested in making a better world.
fgmasdr IOhannes
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
There is no way to peace, peace is the way. -A.J. Muste