Currently there are some abstractions shipped with Gem in the Gem/ dir, but if you load Gem, it'll find Gem/Gem.pd_linux, and then never add Gem/ to the search path so that its possible to load the abstractions without a 'Gem/' prefix.
How about adding Gem/ to the searchpath when Gem is loaded? I think gridflow does this and it seems to work well there.
.hc
----------------------------------------------------------------------------
Programs should be written for people to read, and only incidentally for machines to execute. - from Structure and Interpretation of Computer Programs
On 04/04/2011 11:11 PM, Hans-Christoph Steiner wrote:
Currently there are some abstractions shipped with Gem in the Gem/ dir, but if you load Gem, it'll find Gem/Gem.pd_linux, and then never add Gem/ to the search path so that its possible to load the abstractions without a 'Gem/' prefix.
How about adding Gem/ to the searchpath when Gem is loaded? I think gridflow does this and it seems to work well there.
actually Gem does this as well (at least it should). the trick is, that it has to find s_stuff.h at configure time to enable this feature (as it depends on this header for inclusion) [1]
all the logic is done in Base/GemSetup.cpp
fgmasdr IOhannes
[1] if it doesn't find the header during configure, please go ahead and find out why.
On Apr 5, 2011, at 3:05 AM, IOhannes zmölnig wrote:
On 04/04/2011 11:11 PM, Hans-Christoph Steiner wrote:
Currently there are some abstractions shipped with Gem in the Gem/ dir, but if you load Gem, it'll find Gem/Gem.pd_linux, and then never add Gem/ to the search path so that its possible to load the abstractions without a 'Gem/' prefix.
How about adding Gem/ to the searchpath when Gem is loaded? I think gridflow does this and it seems to work well there.
actually Gem does this as well (at least it should). the trick is, that it has to find s_stuff.h at configure time to enable this feature (as it depends on this header for inclusion) [1]
all the logic is done in Base/GemSetup.cpp
From my Pd-extended point of view, not finding s_stuff.h is an error, and the build should stop. Here's my fix:
http://pure-data.svn.sourceforge.net/viewvc/pure-data?view=revision&revi...
.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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-04-06 22:31, Hans-Christoph Steiner wrote:
From my Pd-extended point of view, not finding s_stuff.h is an error, and the build should stop.
i understand this pov if you have your PdX hat on, but obviously it is inacceptable for Gem in general.
Here's my fix:
http://pure-data.svn.sourceforge.net/viewvc/pure-data?view=revision&revi...
excuse me, but this fix is utterly..., well, i cannot find a word for it. i hope that i have fixed the configure script last night, but with workarounds and hacks like forcing HAVE_STUFF_H, we will never now whether the upstream build-system really fixes the problem.
please don't go for immediate satisfaction at the cost of long term fixes.
fgmasdr IOhannes
On Apr 7, 2011, at 3:10 AM, IOhannes m zmoelnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-04-06 22:31, Hans-Christoph Steiner wrote:
From my Pd-extended point of view, not finding s_stuff.h is an error, and the build should stop.
i understand this pov if you have your PdX hat on, but obviously it is inacceptable for Gem in general.
Here's my fix:
http://pure-data.svn.sourceforge.net/viewvc/pure-data?view=revision&revi...
excuse me, but this fix is utterly..., well, i cannot find a word for it. i hope that i have fixed the configure script last night, but with workarounds and hacks like forcing HAVE_STUFF_H, we will never now whether the upstream build-system really fixes the problem.
please don't go for immediate satisfaction at the cost of long term fixes.
I think you're missing the point a bit. My fix was a better long term fix for the problem I was trying to solve: making a missing s_stuff.h stop the Pd-extended build with an error. For Pd-extended, I am not interested in what ./configure finds, I want to build using a given configuration, and it should fail when there is something missing, not configure around it. Same goes for making a Debian (or whatever) package.
I suppose its possible to do something similar in Gem's build system, but its really far too complex for mere mortals to understand.
.hc
----------------------------------------------------------------------------
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 -
IOhannes m zmoelnig -
IOhannes zmölnig