Hey hans++,
I'm just getting back into pT development and downloaded the latest autobuild pd-extended. (test5)
Seems a few things are not quite working yet. When I start pd-extended I get:
Gem: can't load library iemmatrix: can't load library mtx: can't load library pdp: can't load library pidip: can't load library
I see that "Gem" is not in the extended release, I guess due to the gem build issues.
Since the ftgl and freetype libs don't change much should they just be compilied manually and copied onto the compile farm? Looks like the OSX gem terminal build is pretty close to being ready according to IOhannes.
also seems pool is missing. I guess I'll have to checkout everything on the laptop and try and build the whole monster myself and see whats going on.
Hans, what is the most recent build of pd-extended 0.39 that works? (as in as well as the older test1 test builds did?)
Thanks all. I can help with compiling stuff on OSX/Linux but where are we at for getting Gem into the autobuild? Are the gem sources in a place where the build can get them?
.b.
On Aug 10, 2006, at 4:23 PM, B. Bogart wrote:
Hey hans++,
I'm just getting back into pT development and downloaded the latest autobuild pd-extended. (test5)
Seems a few things are not quite working yet. When I start pd- extended I get:
Gem: can't load library iemmatrix: can't load library mtx: can't load library pdp: can't load library pidip: can't load library
I see that "Gem" is not in the extended release, I guess due to the gem build issues.
Since the ftgl and freetype libs don't change much should they just be compilied manually and copied onto the compile farm? Looks like the OSX gem terminal build is pretty close to being ready according to IOhannes.
CVS or native-OS package management are the only options for the auto- build farm. FTGL and FreeType should just be checked into CVS, i.e. GemLibs, if they are not included in Fink/Debian/Fedora Core
also seems pool is missing. I guess I'll have to checkout everything on the laptop and try and build the whole monster myself and see whats going on.
No one's gotten that stuff working with the Pd-extended build system. The flext build stuff is strange and it seems Gem is making progress with the ./configure stuff. Really, its just a matter of someone doing the work. If either build system uses the GNU standard 'DESTDIR' and 'prefix' variables correctly, then the install targets should be easy. Otherwise those will have to be implemented.
Hans, what is the most recent build of pd-extended 0.39 that works? (as in as well as the older test1 test builds did?)
The manually assembled test versions have Gem and flext binaries in them:
http://at.or.at/hans/pd/installers.html
I am no longer doing manual test versions.
Thanks all. I can help with compiling stuff on OSX/Linux but where are we at for getting Gem into the autobuild? Are the gem sources in a place where the build can get them?
This is all up the gem devs. The framework is in place, Gem just needs to be plugged in.
.hc
.b.
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
Hans-Christoph Steiner wrote:
also seems pool is missing. I guess I'll have to checkout everything on the laptop and try and build the whole monster myself and see whats going on.
No one's gotten that stuff working with the Pd-extended build system. The flext build stuff is strange and it seems Gem is making progress with the ./configure stuff. Really, its just a matter of someone doing the work. If either build system uses the GNU standard 'DESTDIR' and 'prefix' variables correctly, then the install targets should be easy. Otherwise those will have to be implemented.
Hi Thomas,
So can (we/you) alter the flext buildsys so that things like the DESTDIR and prefix variables (if they are set) provide reasonable defaults to the conf files?
Hans, are these all environment variables or variables within the makefile? As in do we need flext to build like this:
build.sh pd gcc build.sh pd gcc install $DESTDIR $prefix
or can we just run "build.sh pd gcc" with the environment vars set properly?
I'll help were I can, It would be really nice to have flext play nice with the pd-extended build system.
.b.
On Aug 10, 2006, at 7:53 PM, B. Bogart wrote:
Hans-Christoph Steiner wrote:
also seems pool is missing. I guess I'll have to checkout everything on the laptop and try and build the whole monster myself and see whats going on.
No one's gotten that stuff working with the Pd-extended build system. The flext build stuff is strange and it seems Gem is making progress with the ./configure stuff. Really, its just a matter of someone doing the work. If either build system uses the GNU standard 'DESTDIR' and 'prefix' variables correctly, then the install targets should be easy. Otherwise those will have to be implemented.
Hi Thomas,
So can (we/you) alter the flext buildsys so that things like the DESTDIR and prefix variables (if they are set) provide reasonable defaults to the conf files?
Hans, are these all environment variables or variables within the makefile? As in do we need flext to build like this:
build.sh pd gcc build.sh pd gcc install $DESTDIR $prefix
or can we just run "build.sh pd gcc" with the environment vars set properly?
They are make variables, which are kind of interchangable with env vars. Usually, you would use them like this:
make DESTDIR=/tmp/ prefix=/usr install
but you can also do this:
export DESTDIR=/tmp/ export prefix=/usr make install
I'll help were I can, It would be really nice to have flext play nice with the pd-extended build system.
It would be nice to have Gem and flext working this way. What needs to happen is:
a) there needs to be some command line call to build everything, whether its ./configure && make or whatever.
b) the build system needs to use the standard GNU install variables, so that they can be overridden easily by the Pd-extended build system.
Here are the GNU standard variables for installation directories:
http://theory.uwinnipeg.ca/gnu/make/make_117.html#SEC116
For Pd, since its an odd layout, I had to had a few more, while trying to keep in the spirit of the GNU standards (from packages/ Makefile.buildlayout):
--------------- ifeq ($(OS_NAME),darwin) libpddir = $(DESTDIR)$(prefix) libpdbindir = $(bindir) else ifeq ($(OS_NAME),windows) libpddir = $(DESTDIR)$(prefix) libpdbindir = $(bindir) else libpddir = $(libdir)/pd libpdbindir = $(libpddir)/bin endif endif
objectsdir = $(libpddir)/extra pddocdir = $(libpddir)/doc helpdir = $(pddocdir)/5.reference ----------------
For Pd-extended, there are three more: ---------------- examplesdir = $(pddocdir)/examples manualsdir = $(pddocdir)/manuals readmesdir = $(manualsdir)/READMEs ----------------
I hope that's clear enough, let me know if you have any specific questions...
.hc
Hi all, i appreciate your engagement for the pd-extended build system but because of large concert projects in the next weeks (or rather months) i'm currently not able to help you with it. I see three possibilities: - you are using the strange flext build system which is fairly ok documented by writing proper configuration files with your sane build system - you are not using the strange flext build system by building flext and flext-based externals with your straightforward make files - i can help you with the few relevant preprocessor symbols - you are not going to include flext and flext-based externals at all in the pd-extended system
all the best, Thomas
Am 11.08.2006 um 02:51 schrieb Hans-Christoph Steiner:
On Aug 10, 2006, at 7:53 PM, B. Bogart wrote:
Hans-Christoph Steiner wrote:
also seems pool is missing. I guess I'll have to checkout everything on the laptop and try and build the whole monster myself and see whats going on.
No one's gotten that stuff working with the Pd-extended build system. The flext build stuff is strange and it seems Gem is making progress with the ./configure stuff. Really, its just a matter of someone doing the work. If either build system uses the GNU standard 'DESTDIR' and 'prefix' variables correctly, then the install targets should be easy. Otherwise those will have to be implemented.
Hi Thomas,
So can (we/you) alter the flext buildsys so that things like the DESTDIR and prefix variables (if they are set) provide reasonable defaults to the conf files?
Hans, are these all environment variables or variables within the makefile? As in do we need flext to build like this:
build.sh pd gcc build.sh pd gcc install $DESTDIR $prefix
or can we just run "build.sh pd gcc" with the environment vars set properly?
They are make variables, which are kind of interchangable with env vars. Usually, you would use them like this:
make DESTDIR=/tmp/ prefix=/usr install
but you can also do this:
export DESTDIR=/tmp/ export prefix=/usr make install
I'll help were I can, It would be really nice to have flext play nice with the pd-extended build system.
It would be nice to have Gem and flext working this way. What needs to happen is:
a) there needs to be some command line call to build everything, whether its ./configure && make or whatever.
b) the build system needs to use the standard GNU install variables, so that they can be overridden easily by the Pd-extended build system.
Here are the GNU standard variables for installation directories:
http://theory.uwinnipeg.ca/gnu/make/make_117.html#SEC116
For Pd, since its an odd layout, I had to had a few more, while trying to keep in the spirit of the GNU standards (from packages/ Makefile.buildlayout):
ifeq ($(OS_NAME),darwin) libpddir = $(DESTDIR)$(prefix) libpdbindir = $(bindir) else ifeq ($(OS_NAME),windows) libpddir = $(DESTDIR)$(prefix) libpdbindir = $(bindir) else libpddir = $(libdir)/pd libpdbindir = $(libpddir)/bin endif endif
objectsdir = $(libpddir)/extra pddocdir = $(libpddir)/doc helpdir = $(pddocdir)/5.reference
For Pd-extended, there are three more:
examplesdir = $(pddocdir)/examples manualsdir = $(pddocdir)/manuals readmesdir = $(manualsdir)/READMEs
I hope that's clear enough, let me know if you have any specific questions...
.hc
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Thomas Grill http://grrrr.org
Hello Thomas,
Sorry I've taken so long to get back to you.
To me option B, to make pd-extended makefiles that build flext w/out the flext build system, seems the best option.
Of course I (personally) have little/no understanding of those makefiles.
Do you have examples of stand-alone makefiles to build the flext static lib and a flext external? Perhaps based on my PSO code in CVS?
When you have time.
Hans, how does that sound to you?
.b.
Thomas Grill wrote:
Hi all, i appreciate your engagement for the pd-extended build system but because of large concert projects in the next weeks (or rather months) i'm currently not able to help you with it. I see three possibilities:
- you are using the strange flext build system which is fairly ok
documented by writing proper configuration files with your sane build system
- you are not using the strange flext build system by building flext and
flext-based externals with your straightforward make files - i can help you with the few relevant preprocessor symbols
- you are not going to include flext and flext-based externals at all in
the pd-extended system
all the best, Thomas
Am 11.08.2006 um 02:51 schrieb Hans-Christoph Steiner:
On Aug 10, 2006, at 7:53 PM, B. Bogart wrote:
Hans-Christoph Steiner wrote:
also seems pool is missing. I guess I'll have to checkout everything on the laptop and try and build the whole monster myself and see whats going on.
No one's gotten that stuff working with the Pd-extended build system. The flext build stuff is strange and it seems Gem is making progress with the ./configure stuff. Really, its just a matter of someone doing the work. If either build system uses the GNU standard 'DESTDIR' and 'prefix' variables correctly, then the install targets should be easy. Otherwise those will have to be implemented.
Hi Thomas,
So can (we/you) alter the flext buildsys so that things like the DESTDIR and prefix variables (if they are set) provide reasonable defaults to the conf files?
Hans, are these all environment variables or variables within the makefile? As in do we need flext to build like this:
build.sh pd gcc build.sh pd gcc install $DESTDIR $prefix
or can we just run "build.sh pd gcc" with the environment vars set properly?
They are make variables, which are kind of interchangable with env vars. Usually, you would use them like this:
make DESTDIR=/tmp/ prefix=/usr install
but you can also do this:
export DESTDIR=/tmp/ export prefix=/usr make install
I'll help were I can, It would be really nice to have flext play nice with the pd-extended build system.
It would be nice to have Gem and flext working this way. What needs to happen is:
a) there needs to be some command line call to build everything, whether its ./configure && make or whatever.
b) the build system needs to use the standard GNU install variables, so that they can be overridden easily by the Pd-extended build system.
Here are the GNU standard variables for installation directories:
http://theory.uwinnipeg.ca/gnu/make/make_117.html#SEC116
For Pd, since its an odd layout, I had to had a few more, while trying to keep in the spirit of the GNU standards (from packages/Makefile.buildlayout):
ifeq ($(OS_NAME),darwin) libpddir = $(DESTDIR)$(prefix) libpdbindir = $(bindir) else ifeq ($(OS_NAME),windows) libpddir = $(DESTDIR)$(prefix) libpdbindir = $(bindir) else libpddir = $(libdir)/pd libpdbindir = $(libpddir)/bin endif endif
objectsdir = $(libpddir)/extra pddocdir = $(libpddir)/doc helpdir = $(pddocdir)/5.reference
For Pd-extended, there are three more:
examplesdir = $(pddocdir)/examples manualsdir = $(pddocdir)/manuals readmesdir = $(manualsdir)/READMEs
I hope that's clear enough, let me know if you have any specific questions...
.hc
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Thomas Grill http://grrrr.org
I am sick of build problems, so I am not going to do it. But I'll answer questions where I can.
There is some documentation of the Pd-extended makefiles here:
http://puredata.org/docs/developer
.hc
On Sep 2, 2006, at 12:13 PM, B. Bogart wrote:
Hello Thomas,
Sorry I've taken so long to get back to you.
To me option B, to make pd-extended makefiles that build flext w/ out the flext build system, seems the best option.
Of course I (personally) have little/no understanding of those makefiles.
Do you have examples of stand-alone makefiles to build the flext static lib and a flext external? Perhaps based on my PSO code in CVS?
When you have time.
Hans, how does that sound to you?
.b.
Thomas Grill wrote:
Hi all, i appreciate your engagement for the pd-extended build system but because of large concert projects in the next weeks (or rather months) i'm currently not able to help you with it. I see three possibilities:
- you are using the strange flext build system which is fairly ok
documented by writing proper configuration files with your sane build system
- you are not using the strange flext build system by building
flext and flext-based externals with your straightforward make files - i can help you with the few relevant preprocessor symbols
- you are not going to include flext and flext-based externals at
all in the pd-extended system
all the best, Thomas
Am 11.08.2006 um 02:51 schrieb Hans-Christoph Steiner:
On Aug 10, 2006, at 7:53 PM, B. Bogart wrote:
Hans-Christoph Steiner wrote:
also seems pool is missing. I guess I'll have to checkout everything on the laptop and try and build the whole monster myself and see whats going on.
No one's gotten that stuff working with the Pd-extended build system. The flext build stuff is strange and it seems Gem is making progress with the ./configure stuff. Really, its just a matter of someone doing the work. If either build system uses the GNU standard 'DESTDIR' and 'prefix' variables correctly, then the install targets should be easy. Otherwise those will have to be implemented.
Hi Thomas,
So can (we/you) alter the flext buildsys so that things like the DESTDIR and prefix variables (if they are set) provide reasonable defaults to the conf files?
Hans, are these all environment variables or variables within the makefile? As in do we need flext to build like this:
build.sh pd gcc build.sh pd gcc install $DESTDIR $prefix
or can we just run "build.sh pd gcc" with the environment vars set properly?
They are make variables, which are kind of interchangable with env vars. Usually, you would use them like this:
make DESTDIR=/tmp/ prefix=/usr install
but you can also do this:
export DESTDIR=/tmp/ export prefix=/usr make install
I'll help were I can, It would be really nice to have flext play nice with the pd-extended build system.
It would be nice to have Gem and flext working this way. What needs to happen is:
a) there needs to be some command line call to build everything, whether its ./configure && make or whatever.
b) the build system needs to use the standard GNU install variables, so that they can be overridden easily by the Pd-extended build system.
Here are the GNU standard variables for installation directories:
http://theory.uwinnipeg.ca/gnu/make/make_117.html#SEC116
For Pd, since its an odd layout, I had to had a few more, while trying to keep in the spirit of the GNU standards (from packages/Makefile.buildlayout):
ifeq ($(OS_NAME),darwin) libpddir = $(DESTDIR)$(prefix) libpdbindir = $(bindir) else ifeq ($(OS_NAME),windows) libpddir = $(DESTDIR)$(prefix) libpdbindir = $(bindir) else libpddir = $(libdir)/pd libpdbindir = $(libpddir)/bin endif endif
objectsdir = $(libpddir)/extra pddocdir = $(libpddir)/doc helpdir = $(pddocdir)/5.reference
For Pd-extended, there are three more:
examplesdir = $(pddocdir)/examples manualsdir = $(pddocdir)/manuals readmesdir = $(manualsdir)/READMEs
I hope that's clear enough, let me know if you have any specific questions...
.hc
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Thomas Grill http://grrrr.org
------------------------------------------------------------------------
If you are not part of the solution, you are part of the problem.
Hans-Christoph Steiner wrote:
On Aug 10, 2006, at 4:23 PM, B. Bogart wrote:
I see that "Gem" is not in the extended release, I guess due to the gem build issues.
Since the ftgl and freetype libs don't change much should they just be compilied manually and copied onto the compile farm? Looks like the OSX gem terminal build is pretty close to being ready according to IOhannes.
CVS or native-OS package management are the only options for the auto- build farm. FTGL and FreeType should just be checked into CVS, i.e. GemLibs, if they are not included in Fink/Debian/Fedora Core
honestly i do not see a reason why _i_ should have to go through all the troubles to make FTGL compile from the command line on a platform that does not natively support this. i _do_ have managed to build FTGL via autoconf/make, but it is not the _official_ way to build it and the build might have issues (e.g. i used the X11 openGL which might not be such a good idea in general). building freetype2 on os-x via autoconf is pretty easy, but (afaik) it _needs_ to be "install"ed in order to function properly, which involves privileges i would not grant on an autobuild farm. (i might be wrong here though)
the simplest way i could think of (in terms of maintainability) is to provide binary GemLibs packages for special platforms: e.g. GemLibs/lib/ftgl.a and GemLibs/include/freetype2/
so we just need to add "-I${GEMLIBS}/include" and "-L${GEMLIBS}/lib" to the default make-flags.
another possibility would be to not have FTGL-support on the autobuilt Gem (after all font-rendering is really an optional feature).
mfg.adsf. IOhannes
IOhannes m zmölnig wrote:
honestly i do not see a reason why _i_ should have to go through all the troubles to make FTGL compile from the command line on a platform that does not natively support this.
by this i really only mean the troubles caused by compiling FTGL by a non-gui build-system.
mfg.adsr IOhannes
On Aug 11, 2006, at 6:50 AM, IOhannes m zmölnig wrote:
IOhannes m zmölnig wrote:
honestly i do not see a reason why _i_ should have to go through all the troubles to make FTGL compile from the command line on a platform that does not natively support this.
by this i really only mean the troubles caused by compiling FTGL by a non-gui build-system.
Which GUI do you need to build FTGL? XCode has command line tools. I use them to automatically build libHIDUtilities.a.
.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 Aug 11, 2006, at 4:37 AM, IOhannes m zmölnig wrote:
Hans-Christoph Steiner wrote:
On Aug 10, 2006, at 4:23 PM, B. Bogart wrote:
I see that "Gem" is not in the extended release, I guess due to the gem build issues.
Since the ftgl and freetype libs don't change much should they just be compilied manually and copied onto the compile farm? Looks like the OSX gem terminal build is pretty close to being ready according to IOhannes.
CVS or native-OS package management are the only options for the auto- build farm. FTGL and FreeType should just be checked into CVS, i.e. GemLibs, if they are not included in Fink/Debian/Fedora Core
honestly i do not see a reason why _i_ should have to go through all the troubles to make FTGL compile from the command line on a platform that does not natively support this.
We are talking about managing files on 10+ machines running Windows, Mac OS X 10.3 and 104, and Ubuntu, Fedora Core, and Debian, on PowerPC and x86. I have better things to do that track down all this stuff and build it from source.
i _do_ have managed to build FTGL via autoconf/make, but it is not the _official_ way to build it and the build might have issues (e.g. i used the X11 openGL which might not be such a good idea in general). building freetype2 on os-x via autoconf is pretty easy, but (afaik) it _needs_ to be "install"ed in order to function properly, which involves privileges i would not grant on an autobuild farm. (i might be wrong here though)
the simplest way i could think of (in terms of maintainability) is to provide binary GemLibs packages for special platforms: e.g. GemLibs/lib/ftgl.a and GemLibs/include/freetype2/
so we just need to add "-I${GEMLIBS}/include" and "-L${GEMLIBS}/ lib" to the default make-flags.
another possibility would be to not have FTGL-support on the autobuilt Gem (after all font-rendering is really an optional feature).
Another option, which I think would be the best use of time, would be to make packages for the various OS's. I think Debian might have FTGL packages already, and Fink is a Debian derivative, so a Fink package should be pretty easy to do. I don't know about Fedora Core, but Nando expressed interest in making packages for dependencies for PlanetCCRMA.
.hc
------------------------------------------------------------------------
Using ReBirth is like trying to play an 808 with a long stick. - David Zicarelli
Hey Hans,
I think Johannes's real argument is that FTGL is "done" and is probably not going to change at all anymore. Due to this it takes less time to build the FTGL static libs on each platform than it is to make FTGL play nice in the autobuild system, when the sources will not change. Of course bugs *could* come up though...
Seems like freetype2 compiles fine from the cmd line for all platforms.
So whats the next step?
..b..
Hans-Christoph Steiner wrote:
We are talking about managing files on 10+ machines running Windows, Mac OS X 10.3 and 104, and Ubuntu, Fedora Core, and Debian, on PowerPC and x86. I have better things to do that track down all this stuff and build it from source.
I understand that. But still, managing source builds is a lot of work when multiplied by 10+, even when the software is "done". I don't want to have to build it even once. Right now, I can install many, many packages using Fink/apt-get/yum with basically one command: "fink install ..." or "apt-get install ..." or "yum install ..."
.hc
On Aug 11, 2006, at 12:52 PM, B. Bogart wrote:
Hey Hans,
I think Johannes's real argument is that FTGL is "done" and is probably not going to change at all anymore. Due to this it takes less time to build the FTGL static libs on each platform than it is to make FTGL play nice in the autobuild system, when the sources will not change. Of course bugs *could* come up though...
Seems like freetype2 compiles fine from the cmd line for all platforms.
So whats the next step?
..b..
Hans-Christoph Steiner wrote:
We are talking about managing files on 10+ machines running Windows, Mac OS X 10.3 and 104, and Ubuntu, Fedora Core, and Debian, on PowerPC and x86. I have better things to do that track down all this stuff and build it from source.
------------------------------------------------------------------------
Man has survived hitherto because he was too ignorant to know how to realize his wishes. Now that he can realize them, he must either change them, or perish. -William Carlos Williams
True...
I have a sickly feeling that fink packages of FTGL will be linked against the X11 GLX, and not the native OSX one... maybe thats unfounded.
By XCode terminal utilities do you mean gcc, make etc.. or are there ways of running Xcode from the terminal? Let me know how to did it and I'll download FTGL and see if its possible.
.b.
Hans-Christoph Steiner wrote:
I understand that. But still, managing source builds is a lot of work when multiplied by 10+, even when the software is "done". I don't want to have to build it even once. Right now, I can install many, many packages using Fink/apt-get/yum with basically one command: "fink install ..." or "apt-get install ..." or "yum install ..."
.hc
On Aug 11, 2006, at 12:52 PM, B. Bogart wrote:
Hey Hans,
I think Johannes's real argument is that FTGL is "done" and is probably not going to change at all anymore. Due to this it takes less time to build the FTGL static libs on each platform than it is to make FTGL play nice in the autobuild system, when the sources will not change. Of course bugs *could* come up though...
Seems like freetype2 compiles fine from the cmd line for all platforms.
So whats the next step?
..b..
Hans-Christoph Steiner wrote:
We are talking about managing files on 10+ machines running Windows, Mac OS X 10.3 and 104, and Ubuntu, Fedora Core, and Debian, on PowerPC and x86. I have better things to do that track down all this stuff and build it from source.
Man has survived hitherto because he was too ignorant to know how to realize his wishes. Now that he can realize them, he must either change them, or perish. -William Carlos Williams
hans@sla:hid > grep -C3 xcodebuild ~/cvs/pure-data/externals/Makefile # Apple changed the XCode CLI tool's name in xcode2... arg # if on non-Mac OS X, this target just echos a message cd $(HID_UTILITIES_SOURCE) && \ (test -x /usr/bin/xcodebuild && /usr/bin/xcodebuild) || \ (test -x /usr/bin/pbxbuild && /usr/bin/ pbxbuild) || \ echo "Not building Apple HID Utilities"
.hc
On Aug 11, 2006, at 1:21 PM, B. Bogart wrote:
True...
I have a sickly feeling that fink packages of FTGL will be linked against the X11 GLX, and not the native OSX one... maybe thats unfounded.
By XCode terminal utilities do you mean gcc, make etc.. or are there ways of running Xcode from the terminal? Let me know how to did it and I'll download FTGL and see if its possible.
.b.
Hans-Christoph Steiner wrote:
I understand that. But still, managing source builds is a lot of work when multiplied by 10+, even when the software is "done". I don't want to have to build it even once. Right now, I can install many, many packages using Fink/apt-get/yum with basically one command: "fink install ..." or "apt-get install ..." or "yum install ..."
.hc
On Aug 11, 2006, at 12:52 PM, B. Bogart wrote:
Hey Hans,
I think Johannes's real argument is that FTGL is "done" and is probably not going to change at all anymore. Due to this it takes less time to build the FTGL static libs on each platform than it is to make FTGL play nice in the autobuild system, when the sources will not change. Of course bugs *could* come up though...
Seems like freetype2 compiles fine from the cmd line for all platforms.
So whats the next step?
..b..
Hans-Christoph Steiner wrote:
We are talking about managing files on 10+ machines running Windows, Mac OS X 10.3 and 104, and Ubuntu, Fedora Core, and Debian, on PowerPC and x86. I have better things to do that track down all this stuff and build it from source.
Man has survived hitherto because he was too ignorant to know how to realize his wishes. Now that he can realize them, he must either change them, or perish. -William Carlos Williams
------------------------------------------------------------------------
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
On Aug 11, 2006, at 1:21 PM, B. Bogart wrote:
I have a sickly feeling that fink packages of FTGL will be linked against the X11 GLX, and not the native OSX one... maybe thats unfounded.
...there is no ftgl in fink...but it might be a good idea since it's development is frozen: you could make ftgl-x11 and ftgl-agl versions
By XCode terminal utilities do you mean gcc, make etc.. or are there ways of running Xcode from the terminal? Let me know how to did it and I'll download FTGL and see if its possible.
xcodebuild
jamie
On 8/11/06, Hans-Christoph Steiner hans@eds.org wrote:
I understand that. But still, managing source builds is a lot of work when multiplied by 10+, even when the software is "done". I don't want to have to build it even once. Right now, I can install many, many packages using Fink/apt-get/yum with basically one command: "fink install ..." or "apt-get install ..." or "yum install ..."
Someone could provide prebuilt FTGL andf freetype libs for OSX and Windows.
What are you doing for the Intel builds on the Mac?
cgc
On Aug 11, 2006, at 1:45 PM, chris clepper wrote:
On 8/11/06, Hans-Christoph Steiner hans@eds.org wrote:
I understand that. But still, managing source builds is a lot of work when multiplied by 10+, even when the software is "done". I don't want to have to build it even once. Right now, I can install many, many packages using Fink/apt-get/yum with basically one command: "fink install ..." or "apt-get install ..." or "yum install ..."
Someone could provide prebuilt FTGL andf freetype libs for OSX and Windows.
I think that checking binaries into CVS would be a really bad idea. It will cause more problems than its worth since there are many platforms, like G3, G4, G4, Intel Mac. There is already a lot of support built into the Pd-extended build system to do CPU-specific compiles. If this code is done, then automatically building it should not be hard.
What are you doing for the Intel builds on the Mac?
Nothing, I have no access to an Intel Mac. Any volunteers?
.hc
-
B. Bogart -
chris clepper -
Hans-Christoph Steiner -
IOhannes m zmölnig -
james tittle -
Thomas Grill