Re: build process and portability

[Tom Lord]

       > Nah.  Just write unconditionally portable code.

       Unfortunately sometimes there is no unconditionally portable way to
       perform a particular task. 

I agree.  My recommendation is slightly exaggerated, but essentially
serious.

The core of Guile and nearly all of an OS interface can be coded very
portably -- no autoconf needed.

I'd bet that nearly all features that are less portable can be coded
as non-autoconfed but optional add-ons.

I've found this approach to be simple and clean and easier to
maintain.


        One example would be examining the set of mounted or mountable
        volumes. If you want to write a program that can deal with volumes on
        many unix systems, you must write conditional code. Another classic
        example is terminal handling - you can't do it the same way on SysV
        and BSD.

Push these things out of the core.


        Other times, the most portable way of doing something is not the most
        desirable on systems when better alternatives exist. For instantce,
        `putenv' inherently and unavoidably leaks memory, so it is better to
        use `setenv' when available.

Are you sure you really need either?  Isn't execve enough for most purposes?
Leave both out and encourage programmers to not rely on them.


        Third, there are times when some systems provide a very
        desirable feature but others do not

Make those optional add-ons.  

I can see how simple uses of configure to select optional add-ons
might be a win.  What I'm not fond of is excessively #ifdef'ed code
and the ever increasing complexity of the configure script tower of
tools.

-t