Re: obsd build include trouble

[Ben Pfaff]

John Darrington <address@hidden> 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