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

[Greg Chicares]

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?

http://lists.nongnu.org/archive/html/lmi/2008-09/msg00009.html
|
| Here's one way that definitely works:
|
| 
http://cvs.savannah.gnu.org/viewvc/lmi/lmi/install_miscellanea.make?r1=1.13&r2=1.14

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:
  http://www.codesourcery.com/public/pooma/pete-2.1.0.tgz
in particular:
  pete-2.1.0/src/PETE/PETE.h
  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:
  some_include_path/pete-2.1.1/et_vector.hpp
  some_include_path/pete-2.1.1/PETE/PETE.h
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
  wx/defs.h
contains
  #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?