* Dave Beckett <[EMAIL PROTECTED]> [060322 08:11]:
> compiler command lines can already be very long - try compiling X or kde
> or gnome. I don't believe anything you write here is a significant
> problem.
As I said, when the upstream maintainer break things, it is often needed
to include those. With large packages coompiling libraries and programs
together some in-tree include flags are needed too. But for compiling
some classic X program you might need a -L flag, but no -I flags.
(Some have -I/usr/X11R6/include, but that is only compatibility to
non-FHS systems and no longer needed nowadays).
Compile systems not showing what flags they use for compiling are a
problem, and I doubt there is any explanation why people introduce
them other than too long command lines.
> > Please consider to either (best persuading
> > upstream, otherwise in the Debian package only) to:
> >
> > 1) Move all header files to the place the compiler
> > would look for them. (i.e. /usr/include)
> >
> > 2) Make the compiler look at the proper place,
> > by changing all #include to <cairo/...>,
> > telling all users of those file to include
> > them that way and removing the -I from
> > cairo.pc to catch all missign places.
>
> I am not going to do either of these. The choice cairo made is
> perfectly acceptable and good, common practice.
I even want to challenge the common practise part. Even the related
libraries glib, atk, gdk, gtk do not place things this way, but
have the -I madness only to differentiate between different versions,
any version-less directory names are properly placed in the #include
directives.
> I am not convinced by any of your argument. You should use pkg-config
> and not try to second-guess what compile/link options it generates.
pkg-config is a way to work around things like uncabable toolsets or
broken libraries. I acknowledge that it should be used for some things.
But I'm talking here about Linux and not something like Windows.
There are enough ways to create libraries in a way that no compile/link
options are needed at all. Using a tool to reduce the problems with
broken libraries is no excuse to generate broken libraries.
Bernhard R. Link
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
