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

[Greg Chicares]

On 2008-11-17 00:32Z, Vaclav Slavik wrote:
> 
> On Fri, 2008-09-19 at 17:37 +0000, Greg Chicares wrote:
>> 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.
> 
> This is causing problems with the Automake build system too -- it is
> currently broken, you have to manually install PETE headers somewhere.

Yes, it's quite peculiar. Earlier in this thread, my "manual"
installation procedure...

http://cvs.savannah.gnu.org/viewvc/lmi/lmi/install_miscellanea.make?r1=1.13&r2=1.14

...is described along with a sort of rationale. AFAICT, the weirdness
is present in PETE itself; I've just tried to find a simple way to use
it without changing the original sources too radically. But if we must
somehow change them in the name of robustness, then I guess that's okay.

> I'm not aware of any PETE packages for Linux (not even for Debian that
> usually has everything), so we can't rely on PETE as a dependency and
> have to build it as part of LMI build process. In other words, it would
> be much preferable to be able to use PETE headers in-place. I'll see if
> I can make it work at least on the Automake side. 

I thought there might be a Debian FreePOOMA, but apparently not:
  http://www.google.com/search?num=100&q=FreePooma+debian
IIRC, neither freepooma.nongnu.org nor the old CodeSourcery POOMA
site has a PETE-only tarball of the PETE version we want.

> To complicate matters even more, the nonstandard, LMI-specific
> et_vector.hpp header is stored in tools/pete-2.1.1, not
> tools/pete-2.1.1/PETE, but is #included as <PETE/et_vector.hpp>. This
> can never work without some installation step, of course. Would it be
> acceptable to move it either into the PETE directory or change the
> #include lines for it?

Here are changes we could make, in increasing order of awfulness.

Not awful at all: change #include lines for 'et_vector.hpp'
in lmi files outside the PETE subdirectory. I don't mind if we
copy that one file into lmi's main trunk, either. Or we could
move it into the PETE directory as you suggest above, if that
really doesn't break anything (including the process of
regenerating other files in the PETE hierarchy).

Not really awful: change the PETE makefile
  lmi/tools/pete-2.1.1/PETE/Tools/makefile
or add another one, e.g.
  lmi/tools/pete-2.1.1/PETE/makefile
to add an 'install' target.

Perhaps awful: alter PETE's own include directives and its
directory structure. I'd prefer to do as little violence to the
original sources as possible. Then again, it's not widely used
(that's a shame), and it's not actively maintained, so maybe
there's little benefit in trying not to keep it fairly intact
(except that we'd have to be very careful not to break it).

Really awful: copy all of PETE into the main lmi trunk instead
of keeping it in a subdirectory. One problem is that it would
then become subject to the 'make check_concinnity' style rules,
which would require vast changes. Another is that complexity
varies as perhaps the square or cube of source-code line count,
and this is ten thousand lines we can keep separated. Yet another
is that once we break a physical barrier by moving code into the
"root" from a subdirectory, it becomes subject to entropy unless
thwarted by active measures; but unchanging code can be kept in
a distinct place at zero Kelvin.