On Apr 19, 2010, at 5:40 AM, IOhannes m zmoelnig wrote:

On 2010-04-19 10:22, IOhannes m zmoelnig wrote:

...

could you enable my ssh-key so i can login to the machine and see what can be done?

oops, i missed the "user: pddev" part in the wiki. i'm now in and trying.

i noticed, that there are several versions of autotools installed on the build machine: in /usr/bin we have autoconf=2.59, whereas in /sw/bin/ there is autoconf=2.63. for reasons unknown to me, the /usr/bin version seems to be called in the autobuild process (conf. beginning of http://autobuild.puredata.info/auto-build/2010-04-19/logs/2010-04-19_03.15.4...)

now it seems that my build-system doesn't work with an autoconf that old. i have therefore bumped the AC_PREREQ to 2.60,

however, this will not magically bring the autobuilds back yet, as they will just fail when checking the available autoconf version.

is there a reason why /sw is not in the PATH?

Some build systems are not happy with the tools provided in /sw, so its good to make them optional. You can add /sw to the PATH within the configure.in, then people will inherit that setting when building on their own machine. I think its just a matter of adding this to the top:

PATH="/sw:${PATH}"

.hc

----------------------------------------------------------------------------

If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of everyone, and the receiver cannot dispossess himself of it. - Thomas Jefferson

On Apr 21, 2010, at 3:09 AM, IOhannes m zmoelnig wrote:

On 2010-04-20 21:04, Hans-Christoph Steiner wrote:

...

...

is there a reason why /sw is not in the PATH?

Some build systems are not happy with the tools provided in /sw, so its good to make them optional. You can add /sw to the PATH within the configure.in, then people will inherit that setting when building on their own machine. I think its just a matter of adding this to the top:

PATH="/sw:${PATH}"

.hc

configure.in is probably a bad choice, as this file has to be processed by binaries found in /sw/bin, rather than has to call binaries in / sw/bin. i guess you meant autogen.sh

anyhow, the problem with that is, that autogen.sh is a generic, and i don't feel like adding every single path anyone might happen to have on their machine :-)

i guess it should be set more on a per-machine basis: after all the sysad of a certain host will always know best, which paths on the machine are relevant, whereas the choices of an upstream developer like me will always be bad.

i will probably add /sw/bin to the path in the master build script/Makefile, if this is ok for you.

I think it should be targeted to where its needed. This sounds too broad, tho I am not sure which Makefile you mean. Why not just do a test against uname to set it in autogen.sh. Something like:

if [ `uname -s` -eq "Darwin" ]; then PATH="/sw:${PATH}" fi

.hc

----------------------------------------------------------------------------

If you are not part of the solution, you are part of the problem.