octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: build trouble on MacOS 10.5 [changeset]


From: Rik
Subject: Re: build trouble on MacOS 10.5 [changeset]
Date: Tue, 22 Dec 2009 21:00:45 -0800

> Regarding the two changesets below
>
>       
> http://www-old.cae.wisc.edu/pipermail/octave-maintainers/2009-December/014360.html
>
>       
> http://www-old.cae.wisc.edu/pipermail/octave-maintainers/2009-December/014364.html
>
> I can push these changes, but don't know enough about the build process to 
> have any confidence that these changes will not an adverse effect unix or 
> windows builds.
>
> Also, in the first, is the patch to Makefile.am the right way to do that? (I 
> really don' t know, but it looks a bit hacky to me).
>
> Anyone have some advice/thoughts?
Adding the extra includes for config.h doesn't seem like it would be an
issue.  It's just one more file to include, and probably superfluous for
most other operating systems.  On the other hand, since this seems to be
required only for MAC builds I would put comments to that effect
everywhere you insert a config.h call.  If you're feeling paranoid you
could protect the config.h calls with #ifdef RUNNING_ON_MAC_VARIABLE. 
This would guarantee that the rest of us don't even see the code and
would document the insertions without requiring a comment.

I am reluctant to rewrite the lex rule for compilation in
src/Makefile.am.  Currently we use configure and automake to work out
the right command to call.  I checked the patch and it does produce the
identical call to that which configure/automake worked out for my Linux
system, but I'm not sure that can be guaranteed into the future.

If you do go ahead, I think this shell rule would be more portable than
Perl:
    mv $@ address@hidden
    echo "#ifdef HAVE_CONFIG_H\n#include <config.h>\n#endif" > $@
    cat address@hidden >> $@
    rm -f @<-t

--Rik


reply via email to

[Prev in Thread] Current Thread [Next in Thread]