Re: [lmi] Working with certain third-party-libraries

[Greg Chicares]

On 2006-10-25 16:25 UTC, Vadim Zeitlin wrote:
>
>  So all I can suggest is to do nothing and rely on having libxml++ headers
> and libraries in the standard locations or in CPPFLAGS/LDFLAGS environment
> variables if they're installed elsewhere.

Okay. We'll change nothing, then.

> On Wed, 25 Oct 2006 15:04:16 +0000 Greg Chicares <address@hidden> wrote:
[where should boost reside for msw?]
> 
> [...] So I'd
> propose to, once again, simply do nothing about this and suppose that boost
> headers are available in the default search path or that their directory is
> specified in CPPFLAGS otherwise.

Documentation change committed 20061026T0108Z. Thanks.

>  Independently of the above, we really, really need to understand what's
> going on with this '/c/'. It breaks everything here (I build with "make
> system_root=''" to remove it) while you apparently can't build without it.
> Why can't we use just /usr/local which doesn't suppose that mingw32 and
> msys are installed in the root of the C: drive?

I suppose I should add more notes to 'msw_msys.make'. But first
let me try to understand your situation.

I suppose you already know that '/c/' is MSYS's equivalent of
cygwin's '/cygdrive/c/'. They mimic a single-root filesystem
on an OS that has multiple roots: 'C:\', 'D:\', etc.

$(system_root) is what the makefiles use as the, um, default
root. It's very simple for posix: '/'. The complexity arises
because my practice (past and future, though sadly not present)
is to build everything from scratch (every twenty-four hours,
in theory) with each of MSYS, cygwin, and my own environment.
If I were doing that at present, perhaps I would already have
found and fixed the problems you're experiencing; but I'm not,
so I have to ask.

Anyway, given the above ideal, I don't really want multiple
copies of, say, all boost headers in...
  C:\usr\local\include
  C:\cygwin\local\include
  C:\msys\1.0\local\include
(IIRC, the last two map /usr/local/ to /usr/). So I put a
single copy in
  C:\usr\local\include
and point the other environments there. To do that, I need
$(system_root). Or at least that seemed like the best way
when I devised this, though I'd welcome a better idea.

> It breaks everything here (I build with "make
> system_root=''" to remove it)

One workaround is to set it in 'local_options.make':
  local_options += system_root=''

> while you apparently can't build without it.

I probably wouldn't be able to build in MSYS without it.
It's been too long since I tried, but I'd hate to strip
out code that once worked great, and then have to reinvent
it later in order to get back to the discipline of building
frequently in multiple environments.

> Why can't we use just /usr/local which doesn't suppose that mingw32 and
> msys are installed in the root of the C: drive?

To me, in my usual environment, /usr/local is
  C:\usr\local\include
but with MSYS it could be
  ANY_DRIVE:\any_path\msys\1.0\local\include
I guess. But that
  ANY_DRIVE:\any_path\
is what I abstracted with $(system_root).

As for gcc, my usual 'local_options.make' says
  local_options += mingw_dir='/MinGW-20050120/'
Here, $(mingw_dir) needs a separate variable, because
I have about five different versions of it installed
and actually have reasons for using more than one.

Along with the makefiles in
  [sources]/lmi/lmi
there are more in
  [sources]/lmi/lmi/gwc
and I think all of them use $(system_root) and, if a
compiler is needed, $(mingw_dir). I've tried to maintain
this abstraction carefully all over the place. What I
don't quite understand, though, is: what's wrong with
that abstraction?