On Tue, Oct 08, 2019 at 01:44:14PM +0200, Jeremie Courreges-Anglas wrote: > On Tue, Oct 08 2019, Christopher Zimmermann <madro...@gmerlin.de> wrote: > > On Mon, Oct 07, 2019 at 09:09:50PM +0100, Stuart Henderson wrote: > >> On 2019/10/07 21:37, Christopher Zimmermann wrote: > >> > How is an arbitrary piece of software supposed to > >> > discover /usr/local/include and /usr/local/lib? > >> > >> The same way it will discover /opt/include and /opt/lib on a linux box - > >> you tell it to look there. > > > > - What's the preferred way to teach a build system our search paths ? > > - What's the preferred / most portable way for a piece of software to > > discover the search paths? > > > > Is it pkg-config, $CPATH / $LIBRARY_PATH, autoconf, something else? > > Many build systems have support for pkg-config (eg pkg.m4 for autoconf). > autoconf honours (at least) CPPFLAGS/CFLAGS/LDFLAGS. > CPATH and LIBRARY_PATH are OCaml idioms AFAIK.
Quite contrary CPATH and LIBRARY_PATH are variables heeded by gcc and
clang compiler and linker.
I did some experiments:
$ echo '#include<bzlib.h>' >incl_test.c
$ CPATH= cc -E -Wp,-v incl_test.c >/dev/null
clang -cc1 version 8.0.1 based upon LLVM 8.0.1 default target
amd64-unknown-openbsd6.6
#include "..." search starts here:
#include <...> search starts here:
/usr/lib/clang/8.0.1/include
/usr/include
End of search list.
incl_test.c:1:9: fatal error: 'bzlib.h' file not found
#include<bzlib.h>
^~~~~~~~~
1 error generated.
$ CPATH=/usr/local/include cc -E -Wp,-v incl_test.c >/dev/null
clang -cc1 version 8.0.1 based upon LLVM 8.0.1 default target
amd64-unknown-openbsd6.6
#include "..." search starts here:
#include <...> search starts here:
/usr/local/include
/usr/lib/clang/8.0.1/include
/usr/include
But this is _really_ unexpected:
$ CPATH= echo '#include<bzlib.h>' |cc -E -Wp,-v - >/dev/null
clang -cc1 version 8.0.1 based upon LLVM 8.0.1 default target
amd64-unknown-openbsd6.6
#include "..." search starts here:
#include <...> search starts here:
/usr/local/include
/usr/X11R6/include
/usr/lib/clang/8.0.1/include
/usr/include
End of search list.nd of search list
This tells me that the preprocessor has a decent idea of our search
path, but forgets about /usr/local and /usr/X11R6 includes when a file
is passed as argument instead of run in a pipe.
The heck why does it do that?
> There's no single answer.
Of course not.
> Can opam simply inject -I/usr/local/include and -L/usr/local/lib in the
> dune build system used by ocaml-lmdb?
Since the C compiler/linkers heed CPATH and LIBRARY_PATH, I can simply
set those variables to inject the standard search path.
But why do I even have to do that? The preprocessor seems to know the
correct search path, but seems to forget it under some circumstances.
Christopher
--
http://gmerlin.de
OpenPGP: http://gmerlin.de/christopher.pub
CB07 DA40 B0B6 571D 35E2 0DEF 87E2 92A7 13E5 DEE1
signature.asc
Description: PGP signature
