[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] building latest cvs with MSVC (PETE paths)

From: Greg Chicares
Subject: Re: [lmi] building latest cvs with MSVC (PETE paths)
Date: Fri, 19 Sep 2008 17:37:59 +0000
User-agent: Thunderbird (Windows/20080708)

On 2008-09-19 11:57Z, Vadim Zeitlin wrote:
>  I'm rebuilding latest cvs with MSVC and had 2 new problems:
> 1. My MSVC patch needs to be applied to the new functions in mc_enum.tpp:

I haven't yet had time to consider that patch.

> 2. I'm not sure how should the PETE files be organized. Currently loads.cpp
>    contains "#include <PETE/et_vector.hpp>" and this doesn't work for me
>    because the file et_vector.hpp is under tools/pete-2.1.1, i.e. not in
>    PETE subdirectory at all. Shouldn't it be there?

| Here's one way that definitely works:

The 'pete' target in that file boils down to this:

        cp \
          --force --preserve --recursive \
          --target-directory=$(third_party_include_dir)/PETE/ \
          lmi/tools/pete-2.1.1/*.* \
          lmi/tools/pete-2.1.1/PETE/*.* \

The PETE directory structure in lmi cvs is intended to resemble
the structure of the original PETE archive here:
in particular:
  pete-2.1.0/examples/Vector/Eval.h says '#include "PETE/PETE.h"'
with these correspondences:
  pete-2.1.0/src/PETE/        <--> lmi/tools/pete-2.1.1/PETE/
  pete-2.1.0/examples/Vector/ <--> lmi/tools/pete-2.1.1/

The installation command above flattens that structure. ('*.*' is
deliberate: it ignores 'CVS' subdirs and other irrelevant files.)

Why flatten it? Because it didn't work otherwise, at least not with
MinGW gcc--or como either, IIRC.

That did seem strange to me. It worked if I gave the compiler a full
absolute path beginning with '/', but not with a relative path. The
problem seemed to be that with
  -I some_include_path
and files arranged this way:
as in cvs, the preprocessor couldn't find the files that 'PETE.h'
includes. (I'm writing that from memory because I've got a big job
running and can't recreate the problem right now.)

At first, I thought it seemed wrong for 'PETE/PETE.h' to specify
relative paths like this:
  #include "PETE/Scalar.h"
to include files that are in its own directory. But then I looked
at wx, and
  #include "wx/platform.h"
which I'm sure must be right because it's been used by so many
people on so many platforms for so many years. Then I wondered why
I had an error with PETE but not with wx...and it turns out that
I've always specified an absolute path to wx.

Perhaps I'm misunderstanding something; can you help me see it?

reply via email to

[Prev in Thread] Current Thread [Next in Thread]