John Darrington <[EMAIL PROTECTED]> writes:
> If we decide to use the explicit #include model (which I think we
> have), then these pattern specific variable definitions will be
> unnecessary. However, it'll still be useful to have, for example on
> the directory src/ui/gui to add the gtk paths to that directory.
>
> What's the recommended way to do this on a vanilla make ?
We could write Automake rules to link src/ui/gui into a library,
then link the library into the GUI, as described in the Automake
1.9 manual:
What if `foo.c' needs to be compiled into `foo.o' using
some specific flags, that none of the other files require?
Obviously per-program flags are not directly applicable here.
Something like per-object flags are expected, i.e., flags
that would be used only when creating `foo-foo.o'. Automake
does not support that, however this is easy to simulate using
a library that contains only that object, and compiling this
library with per-library flags.
bin_PROGRAMS = foo
foo_SOURCES = bar.c bar.h main.c
foo_CFLAGS = -some -flags
foo_LDADD = libfoo.a
noinst_LIBRARIES = libfoo.a
libfoo_a_SOURCES = foo.c foo.h
libfoo_a_CFLAGS = -some -other -flags
Here `foo-bar.o' and `foo-main.o' will all be compiled
with `-some -flags', while `libfoo_a-foo.o' will be compiled
using `-some -other -flags'. Eventually, all three objects
will be linked to form `foo'.
But I'd guess that the GTK include path doesn't interfere with
anything else, so that we could include it in AM_CPPFLAGS and not
worry about being specific to src/ui/gui.
By the way, should the pspp binary now go in src/ui/terminal, for
symmetry with the gui?
--
"doe not call up Any that you can not put downe."
--H. P. Lovecraft
_______________________________________________
pspp-dev mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/pspp-dev
