> That's neither exceptional nor really problematic. I am confident
> the new Fortran/cpp macros I am developing will handle this.
Nice! I'd like to see those when you are done. For us, gcc does the
preprocessing just fine; df can't do any. IIRC it has the `INCLUDE'
form, but that's no use for our code base that expects C-style #include,
#define and #if stuff.
> (In fact, I'd be grateful if you could do a test on Windows for them
> with this compiler; I know nothing about how autotools work on Windows
> /Cygwin etc.).
Alas, not for the next month or so :-( I do not have a Windows build
environment setup right now and I am about to leave for holidays. I'll
try to see what I can do somewhere around August if that will still be
intersting.
>> df does not understand paths with forward slashes.
> I'd assume the autoconf core handles these issues, but I'm not certain.
2.13 certainly didn't. I haven't followed CVS autoconf developments
closely enough to be able to answer for the current situation. Perhaps
someone knows better.
> Have you tried the F77_NAME_MANGLING stuff in autoconf? I wonder whether
> it can figure out df's behaviour. If it can't we should improve it.
No, I haven't. The main reason for that is that we do not want autoconf
to guess any of the compiler-related things. It doesn't work in this
project (see below). The build environment knows all the details so we
can tell exactly what we are supposed to get, and if something breaks,
we know there is a problem with the system's configuration. In our
environment consistent configurations are very valuable, but having
autoconf guess a wrong value is very expensive.
In our project we have conventions and expectations chosen after a good
deal of research, and we want to get the compiler support our choices --
not the other way around. If we cannot (and only if not!), we design
suitable abstractions that will hide the details from the developers
where possible. The number of such abstractions is kept at minimum --
they are expensive to communicate in our environment. For C/C++/F77 mix
`cfortran.h' does much of the job admirably, but IIRC it didn't
understand df's defaults well.
Another matter is that autoguessing features works only so far. Don't
get me wrong -- autoconf has some very nice uses in this project. But
when you get into the business of determining how to build shared
libraries with F77 compilers on a dozen of unix systems and how to
create source listings and link map files as you go, autoconf sort of
runs out of steam. It's a different problem: getting consistent
configurations for projects with hundreds of packages, plus getting the
features developers reasonably expect -- like profiling, various levels
of optimisations, ability to downgrade optimisations for particular
source files, options for multi-threading, interaction with memory leak
detectors, shared libraries vs. archive libraries... the list goes on.
> So there *is* a way to convince it to process .f files - IMO that's all
> that counts. (unlike your old xlf :-( )
Yes, but if can't do .F, which covers ~100% of our FORTRAN code base :-/
Cheers,
//lat
--
Keep in mind always the two constant Laws of Frisbee:
1) The most powerful force in the world is that of a disc straining
to land under a car, just out of reach (this force is technically
termed "car suck").
2) Never precede any manoeuvre by a comment more predictive than
"Watch this!"
