Can someone tell me how to build the new svn externals? I downloaded from the svn: https://pure-data.svn.sourceforge.net/svnroot/pure-data/trunk/externals
I run make mrpeach [I'm only worried about this external at this time] and I get:
09:20:13 $ make mrpeach Makefile:27: /packages/Makefile.buildlayout: No such file or directory grep: /sigpack/source/sIgpAck.c: No such file or directory grep: /zexy/src/zexy.h: No such file or directory make: *** No rule to make target `/packages/Makefile.buildlayout'. Stop.
The README says to go here: http://puredata.org/docs/developer/
And there I see some information about "Directory Layout for Developers" (but about the old cvs repo) and some other stuff, but no info about how to simply build the externals using make. Is there no step-by-step list of instructions?
It seems to me that in an effort to make things 'easy' and 'centralized' this has actually become more complicated and less easy. It would be easier for me if I could just dl the externals I want, and run 'make' in their respective directories [maybe editing the destination path before I do that]. A larger build script could simply export some environment variable(s) to set global defaults for these paths [if a sane, standard makefile is given to all developers to work from]. Maybe I'm missing some vital information though?
-Alex
Hallo, Alex hat gesagt: // Alex wrote:
Can someone tell me how to build the new svn externals? I downloaded from the svn: https://pure-data.svn.sourceforge.net/svnroot/pure-data/trunk/externals
I run make mrpeach [I'm only worried about this external at this time] and I get:
09:20:13 $ make mrpeach Makefile:27: /packages/Makefile.buildlayout: No such file or directory grep: /sigpack/source/sIgpAck.c: No such file or directory grep: /zexy/src/zexy.h: No such file or directory make: *** No rule to make target `/packages/Makefile.buildlayout'. Stop.
You also need to check out the "packages" directory. In fact, it's best to check out everything in trunk once.
It seems to me that in an effort to make things 'easy' and 'centralized' this has actually become more complicated and less easy. It would be easier for me if I could just dl the externals I want, and run 'make' in their respective directories [maybe editing the destination path before I do that].
This works for some externals, but mrpeach doesn't have its own makefile (AFAIK). The global build system is the only global one actively maintained, so unless someone comes up with and maintains a better one, that's all there is.
Ciao
Frank
On Sat Oct 11, 2008 at 07:15:59PM +0200, Frank Barknecht wrote:
Hallo, Alex hat gesagt: // Alex wrote:
Can someone tell me how to build the new svn externals? I downloaded from the svn: https://pure-data.svn.sourceforge.net/svnroot/pure-data/trunk/externals
I run make mrpeach [I'm only worried about this external at this time] and I get:
09:20:13 $ make mrpeach Makefile:27: /packages/Makefile.buildlayout: No such file or directory grep: /sigpack/source/sIgpAck.c: No such file or directory grep: /zexy/src/zexy.h: No such file or directory make: *** No rule to make target `/packages/Makefile.buildlayout'. Stop.
You also need to check out the "packages" directory. In fact, it's best to check out everything in trunk once.
It seems to me that in an effort to make things 'easy' and 'centralized' this has actually become more complicated and less easy. It would be easier for me if I could just dl the externals I want, and run 'make' in their respective directories [maybe editing the destination path before I do that].
This works for some externals, but mrpeach doesn't have its own makefile (AFAIK). The global build system is the only global one actively maintained, so unless someone comes up with and maintains a better one, that's all there is.
the thing is, there _Was_ sometihng more sane
you know, for dir in */; do cd dir make done
(or the suitable slightly less verbose Makefile way of doing such)
is someone going to revert changes if i go and split up that monster makefile?
Ciao
Frank
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
btw why is additionally depending on ../packages/ and ../build/ and ../scripts/ good?
this change bugged me ever since it occured but i refrained from mentioning, since at least someone was motivated to work on maintenance
imo /externals should be self-sufficient, like it always was
you can no longer move it around and expect it to build...
On Oct 11, 2008, at 1:43 PM, carmen r wrote:
btw why is additionally depending on ../packages/ and ../build/
and ../scripts/ good?this change bugged me ever since it occured but i refrained from
mentioning, since at least someone was motivated to work on
maintenanceimo /externals should be self-sufficient, like it always was
you can no longer move it around and expect it to build...
'externals' cannot be self-sufficient since it will always depend on
the headers in 'pd'.
Most of this organization is bourne of the fact that only Miller can
modify the 'pd' section.
.hc
"It is convenient to imagine a power beyond us because that means we
don't have to examine our own lives.", from "The Idols of
Environmentalism", by Curtis White
'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 directory
see miXed/ it still works that way
the issue is you introduced dependencies on several new toplevel dirs for no good reason
and broke up the modularity of the makefiles
all i'm asking is /scripts and /packages can descend in, and do what they need, without requiring stuff inside to depend on new toplevel stuff
and same for the external makefile - the per-project bits should go in individual Makefiles in the projects, and the top level should just glob them all and make in each (or the dirs specified)
Most of this organization is bourne of the fact that only Miller can
modify the 'pd' section.
well, the extra/ portion of miller's PD should go away too
anyways, im not sure i can log in to the new SVN. im just amazed at how broken everything stil is
i cant even launch PD without it killing all keyboard input (even to Tk/pd-gui itself) until using the mouse to exit.
and it _still_ doesnt find ALSA by default on launch
and the configure script _still_ cant find jack.h
etc
oh well, unsubscribing. have fun in your broken paradise
.hc
"It is convenient to imagine a power beyond us because that means we
don't have to examine our own lives.", from "The Idols of
Environmentalism", by Curtis White
On Sat, 2008-10-11 at 18:57 -0400, carmen r wrote:
and it _still_ doesnt find ALSA by default on launch
pd -alsa
and the configure script _still_ cant find jack.h
../configure --enable-jack
roman
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
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 directory
see miXed/ it still works that way
the issue is you introduced dependencies on several new toplevel dirs for no good reason
and 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
On Oct 13, 2008, at 7:20 AM, IOhannes m zmoelnig 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.
Sounds good to me.
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
Wow, that was a waste of everyone's time. Just come in and bitch at
a lot of people, then bail.
.hc
All mankind is of one author, and is one volume; when one man dies,
one chapter is not torn out of the book, but translated into a better
language; and every chapter must be so translated.... -John Donne
morning all,
On 2008-10-13 20:44:56, Hans-Christoph Steiner hans@eds.org appears to have written:
On Oct 13, 2008, at 7:20 AM, IOhannes m zmoelnig wrote:
carmen r wrote:
and 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.
Sounds good to me.
Likewise.
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.
Wow, that was a waste of everyone's time. Just come in and bitch at
a lot of people, then bail.
I think it falls under "free and open exchange of ideas" ;-)
marmosets, Bryan
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 directory
see miXed/ it still works that way
the issue is you introduced dependencies on several new toplevel dirs for no good reason
and 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
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
On Oct 11, 2008, at 1:33 PM, carmen r wrote:
On Sat Oct 11, 2008 at 07:15:59PM +0200, Frank Barknecht wrote:
Hallo, Alex hat gesagt: // Alex wrote:
Can someone tell me how to build the new svn externals? I downloaded from the svn: https://pure-data.svn.sourceforge.net/svnroot/pure-data/trunk/ externals
I run make mrpeach [I'm only worried about this external at this
time] and I get:09:20:13 $ make mrpeach Makefile:27: /packages/Makefile.buildlayout: No such file or
directory grep: /sigpack/source/sIgpAck.c: No such file or directory grep: /zexy/src/zexy.h: No such file or directory make: *** No rule to make target `/packages/ Makefile.buildlayout'. Stop.You also need to check out the "packages" directory. In fact, it's
best to check out everything in trunk once.It seems to me that in an effort to make things 'easy' and 'centralized' this has actually become more complicated and less
easy. It would be easier for me if I could just dl the externals I want, and run 'make' in their respective directories [maybe editing the destination path before I do that].This works for some externals, but mrpeach doesn't have its own
makefile (AFAIK). The global build system is the only global one actively maintained, so unless someone comes up with and maintains a
better one, that's all there is.the thing is, there _Was_ sometihng more sane
you know, for dir in */; do cd dir make done
(or the suitable slightly less verbose Makefile way of doing such)
Whatever was there is still there. We removed no makefiles in the
process of making that one. That's why it's all in one file.
is someone going to revert changes if i go and split up that
monster makefile?
If you want to improve the build system, that would be very great.
There has been a lot of discussion about how to do this over the
years. Make a proposal how would you do it, and we'll take it from
there.
.hc
Ciao
Frank
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
If you are not part of the solution, you are part of the problem.
-
Alex -
Bryan Jurish -
carmen r -
Frank Barknecht -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
Roman Haefeli