I would like to included Gem in the Pd-extended auto-builds. Anyone up for trying it out? The compile farm is already automatically syncing to the pd-gem CVS every night. Another option is to import a snapshot into the pure-data CVS and build it from there.
.hc
------------------------------------------------------------------------
¡El pueblo unido jamás será vencido!
hans@eds.org wrote:
I would like to included Gem in the Pd-extended auto-builds. Anyone up for trying it out? The compile farm is already automatically syncing to the pd-gem CVS every night. Another option is to import a snapshot into the pure-data CVS and build it from there.
i prefer the former (pulling pd-gem instead of mirroring it into pure-data).
anyhow, i am "up for trying it out", which steps are required on my side?
mfga.dsr. IOhannes
On Jul 27, 2006, at 3:38 AM, IOhannes m zmoelnig wrote:
hans@eds.org wrote:
I would like to included Gem in the Pd-extended auto-builds. Anyone up for trying it out? The compile farm is already automatically syncing to the pd-gem CVS every night. Another option is to import a snapshot into the pure-data CVS and build it from there.
i prefer the former (pulling pd-gem instead of mirroring it into pure-data).
anyhow, i am "up for trying it out", which steps are required on my side?
I think the best way to go about it is to add "gem" and "gem_install" targets to packages/Makefile or packages/linux_make/Makefile. Ideally it would go in the first one since that's used on all platforms. The second option is for things that are platform- specific. Then that "gem" and "gem_install" targets just need to be added to the "all" and "install" targets.
Does ./configure work on all platforms? That would make life much easier. Also, since the WinXP auto-build machine is MinGW-based, it would be quite handy to have ./configure working on MinGW also.
I am working on getting the auto-builds to report failures via email, so people know when they broke something. I am thinking that these emails would then go to pd-dev.
.hc
------------------------------------------------------------------------
I spent 33 years and four months in active military service and during that period I spent most of my time as a high class muscle man for Big Business, for Wall Street and the bankers. - General Smedley Butler
On 7/27/06, hans@eds.org hans@eds.org wrote:
Does ./configure work on all platforms?
From my experience it only works on Linux.
On Jul 27, 2006, at 10:20 AM, chris clepper wrote:
On 7/27/06, hans@eds.org hans@eds.org wrote:
Does ./configure work on all platforms?
From my experience it only works on Linux.
Wasn't there some talk to making ./configure work on Mac OS X?
.hc
------------------------------------------------------------------------
¡El pueblo unido jamás será vencido!
On Jul 27, 2006, at 10:22 AM, hans@eds.org wrote:
On Jul 27, 2006, at 10:20 AM, chris clepper wrote:
On 7/27/06, hans@eds.org hans@eds.org wrote:
Does ./configure work on all platforms?
From my experience it only works on Linux.
Wasn't there some talk to making ./configure work on Mac OS X?
...it used to work, but then I switched back to using xcode...however, some time ago, I did say I'd get it running again, so I guess I should work on that :-\
...my question would be: how am I supposed to deal with the freetype and FTGL dependencies? FTGL is no longer in development, so maybe we do need to put it in cvs/GemLibs? I've generally used a non-standard development environment, where freetype isn't installed in /usr/local or wherever, but instead I use a ~/dev/libs folder for all my self- compiled libs...this is mainly because it allows me more control over whether they are dylibs (and what the install_name is) or statics...
jamie
james tittle wrote:
On Jul 27, 2006, at 10:22 AM, hans@eds.org wrote:
On Jul 27, 2006, at 10:20 AM, chris clepper wrote:
On 7/27/06, hans@eds.org hans@eds.org wrote:
Does ./configure work on all platforms?
From my experience it only works on Linux.
Wasn't there some talk to making ./configure work on Mac OS X?
...it used to work, but then I switched back to using xcode...however, some time ago, I did say I'd get it running again, so I guess I should work on that :-\
...my question would be: how am I supposed to deal with the freetype and FTGL dependencies? FTGL is no longer in development, so maybe we do need to put it in cvs/GemLibs? I've generally used a non-standard
i would rather say, FTGL does what it should do and is therefore "done". imo, the best thing would be, if the autocompiling machine (no matter whether it is linux, osx or w32) has FTGL and freetype installed as prerequisites.
development environment, where freetype isn't installed in /usr/local or wherever, but instead I use a ~/dev/libs folder for all my self-compiled libs...this is mainly because it allows me more control over whether they are dylibs (and what the install_name is) or statics...
which in theory could be handled via proper -I/-L flags to the compiler/linker.
mfga.sdr. IOhannes
hey Io!
...great to see ya back from vacation: hope ya had a good time...
On Jul 27, 2006, at 11:31 AM, IOhannes m zmoelnig wrote:
i would rather say, FTGL does what it should do and is therefore "done".
...yeh, totally agree, since we have no problems atm...
imo, the best thing would be, if the autocompiling machine (no matter whether it is linux, osx or w32) has FTGL and freetype installed as prerequisites.
...that makes since: hans and I've been chatting and think we should import the latest working versions of freetype (2.1.10) and FTGL into GemLibs...or at least FTGL, since that's not available via cvs anywhere else...
development environment, where freetype isn't installed in /usr/ local or wherever, but instead I use a ~/dev/libs folder for all my self-compiled libs...this is mainly because it allows me more control over whether they are dylibs (and what the install_name is) or statics...
which in theory could be handled via proper -I/-L flags to the compiler/linker.
...yeh, I guess this would just be explicitly linking to *.a instead of *.dylib...
...I just went to the freetype site, and noticed that there's now a 2.2.1 in addition to the 2.1.10 series: anyone try it out with gem/ ftgl yet?
...maybe we should meet up on irc?
jamie
james tittle wrote:
hey Io!
...great to see ya back from vacation: hope ya had a good time...
yes it was great. here in graz we have 35 degree C; in shetland they have only 18, which was wonderful!
...that makes since: hans and I've been chatting and think we should import the latest working versions of freetype (2.1.10) and FTGL into GemLibs...or at least FTGL, since that's not available via cvs anywhere else...
right, probably it should be in GemLibs (that is to say: if we don't want to get rid of GemLibs entirely)
...I just went to the freetype site, and noticed that there's now a 2.2.1 in addition to the 2.1.10 series: anyone try it out with gem/ftgl yet?
i am using 2.2.1 here (i never noticed that it changed, i just upgraded my debian system...)
fmga.sdr. IOhannes
On Jul 27, 2006, at 11:31 AM, IOhannes m zmoelnig wrote:
james tittle wrote:
On Jul 27, 2006, at 10:22 AM, hans@eds.org wrote:
On Jul 27, 2006, at 10:20 AM, chris clepper wrote:
On 7/27/06, hans@eds.org hans@eds.org wrote:
Does ./configure work on all platforms?
From my experience it only works on Linux.
Wasn't there some talk to making ./configure work on Mac OS X?
...it used to work, but then I switched back to using xcode...however, some time ago, I did say I'd get it running again, so I guess I should work on that :-\ ...my question would be: how am I supposed to deal with the freetype and FTGL dependencies? FTGL is no longer in development, so maybe we do need to put it in cvs/GemLibs? I've generally used a non-standard
i would rather say, FTGL does what it should do and is therefore "done". imo, the best thing would be, if the autocompiling machine (no matter whether it is linux, osx or w32) has FTGL and freetype installed as prerequisites.
development environment, where freetype isn't installed in /usr/ local or wherever, but instead I use a ~/dev/libs folder for all my self-compiled libs...this is mainly because it allows me more control over whether they are dylibs (and what the install_name is) or statics...
which in theory could be handled via proper -I/-L flags to the compiler/linker.
With the auto-build farm, any dependencies have to be in the OS package system or CVS, otherwise its too much work to maintain. There are going to be 10 machines, I don't want to spend my life maintaining them. MinGW is the only platform where I will build things from source outside of CVS since there is no other option currently. On MinGW, stable releases can be built from source packages, anything else should be in CVS. In other words, if the HOWTO webpage can have a static link to the exact, unchanging source tarball, and that tarball can be built automatically and reliably from scripts/build-libs-for-pd-on-mingw.sh. Otherwise, it needs to be in CVS.
.hc
hans@eds.org wrote:
On Jul 27, 2006, at 3:38 AM, IOhannes m zmoelnig wrote:
hans@eds.org wrote:
I would like to included Gem in the Pd-extended auto-builds. Anyone up for trying it out? The compile farm is already automatically syncing to the pd-gem CVS every night. Another option is to import a snapshot into the pure-data CVS and build it from there.
i prefer the former (pulling pd-gem instead of mirroring it into pure-data).
anyhow, i am "up for trying it out", which steps are required on my side?
I think the best way to go about it is to add "gem" and "gem_install" targets to packages/Makefile or packages/linux_make/Makefile. Ideally it would go in the first one since that's used on all platforms. The second option is for things that are platform-specific. Then that "gem" and "gem_install" targets just need to be added to the "all" and "install" targets.
should the install targets also pull (or at least synchronize) pd-gem from the cvs? where should it go?
Does ./configure work on all platforms? That would make life much
that's what i am saying. alas!, nobody ever found time to make it really work on os-x, though it should be no real problem. it compiles fine, but i think the linking stage is f*ed-up...
easier. Also, since the WinXP auto-build machine is MinGW-based, it would be quite handy to have ./configure working on MinGW also.
that would be really cool, but somebody would have to do it...
I am working on getting the auto-builds to report failures via email, so people know when they broke something. I am thinking that these emails would then go to pd-dev.
they should be reported via email; whether the pd-dev is the right place, should be discussed there...
mffgasdr IOhannes
On Jul 27, 2006, at 11:25 AM, IOhannes m zmoelnig wrote:
hans@eds.org wrote:
On Jul 27, 2006, at 3:38 AM, IOhannes m zmoelnig wrote:
hans@eds.org wrote:
I would like to included Gem in the Pd-extended auto-builds. Anyone up for trying it out? The compile farm is already automatically syncing to the pd-gem CVS every night. Another option is to import a snapshot into the pure-data CVS and build it from there.
i prefer the former (pulling pd-gem instead of mirroring it into pure-data).
anyhow, i am "up for trying it out", which steps are required on my side?
I think the best way to go about it is to add "gem" and "gem_install" targets to packages/Makefile or packages/linux_make/ Makefile. Ideally it would go in the first one since that's used on all platforms. The second option is for things that are platform-specific. Then that "gem" and "gem_install" targets just need to be added to the "all" and "install" targets.
should the install targets also pull (or at least synchronize) pd- gem from the cvs?
cvs operations are handled separately. The install targets should only install files. In the auto-build system, the main server rsyncs from sourceforge, then checked out from the local CVS copy. The other servers then rsync that cvs checkout. In other situations, the human will manage the CVS stuff.
where should it go?
There are Makefile variables for all these locations. They are in packages/Makefile.buildlayout, that's were all of the rest of the Makefiles get them. Look in the section "DIRECTORY STRUCTURE". I think the names should be self-explanatory, but please ask if they are not and I'll document them. There is also documentation here:
https://puredata.org/docs/developer/build
.hc
Does ./configure work on all platforms? That would make life much
that's what i am saying. alas!, nobody ever found time to make it really work on os-x, though it should be no real problem. it compiles fine, but i think the linking stage is f*ed-up...
easier. Also, since the WinXP auto-build machine is MinGW-based, it would be quite handy to have ./configure working on MinGW also.
that would be really cool, but somebody would have to do it...
I am working on getting the auto-builds to report failures via email, so people know when they broke something. I am thinking that these emails would then go to pd-dev.
they should be reported via email; whether the pd-dev is the right place, should be discussed there...
mffgasdr IOhannes
-
chris clepper -
Hans-Christoph Steiner -
hans＠eds.org
-
IOhannes m zmoelnig -
james tittle