Re: Standard Ada Preprocessor

[Ole-Hjalmar Kristensen <ole-hjalmar.kristensen@substitute_employer_here.com>]

Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> writes:

> Ole-Hjalmar Kristensen <ole-hjalmar.kristensen@substitute_employer_here.com> wrote:
> : One way to combat the combinatorial explosion of platforms * compiler
> : * library is to explicitly test for the features of the environment
> : you really need to know, not assume something because of a particular
> : platform/compiler. This is the approach typically used by projects
> : using the 'configure' tool.
> 
> Only to some extent is this test possible with this approach.
> Some GNU software authors must frankly tell you that unless
> you use a know combination of compiler (i.e. gcc ;-) and OS (i.e.,
> Unix or Wunix),
>   "... non-default environments can expose bugs in the system header
>    files, crippling compilation in _very_ non-obvious ways.  Because
>    of that, we define them only on well-tested architectures where we
>    know they will work."
> (from wget config-post.h "1.9+cvs-dev")

Yes, you depend very much on how intelligent the configure scripts are, and you
cannot count on it being automatically portable to another platform,
but in my experience it is more portable and more readable then trying to cover
all platform/compiler/os versions explicitly.

This is from experience of developing/maintaining a > 1000 KLOC project on diverse 
platforms, like FreeBSD, Linux, AIX, HP-UX, Solaris, and Windows for several years.

> 
> And promtly como --c --strict lets me translate the source,
> but without --remarks, it does not tell me that usleep is not
> defined. So for a double argument to usleep which has been
> manually range checked, the conversion to long is not done...
> 
> The configure approach has always been a nightmare for me the moment
> I had to deviate from the assumptions that the configure script
> is known to verify.
> 

Yes, of course. As soon as you introduce new kinds of system dependencies, 
you have to revice the configure script. The hard part is figuring out
which part of your code is really system dependent. You usually find it
out by trying to port your system.

Remember the saying about there is no such thing about portable 
software, only software which has been ported :-)

> : I would really like to have some standard configuration tool which
> : could take such parameters as input and produce a version of the
> : system tailored to the environment in which it is to be compiled and
> : run. 
> 
> Yes. But do you think it will ever be produced by programmers (who
> like to creatively write programs)?
> Collegues tell me that CM is tedious, always the same, automatic,
> boring, wast of time, etc. etc., they want a DWIM procedure.
> And when I answer that configuration
> management, installation procedures, installation testing routines
> and so one are 50% of software development, I'm on my own.
> 
> So the trick will be to turn CM into a programming problem, so
> programmers and mathematicians will be instrested in solving it.
> 
> 
> -- Georg

In addition, you need it to be available without too much effort.
Isn't turning CM into a programming problem exactly what you do by using a 
preprocessor?


-- 
   C++: The power, elegance and simplicity of a hand grenade.