[Ecls-list] ecl 9.4.1 build trouble on Solaris 10/x86

[Gabriel Dos Reis]

On Sat, May 16, 2009 at 5:01 PM, Juan Jose Garcia-Ripoll
<juanjose.garciaripoll at googlemail.com> wrote:
> On Sat, May 16, 2009 at 11:23 PM, Gabriel Dos Reis
> <gdr at integrable-solutions.net> wrote:
>> On Sat, May 16, 2009 at 4:16 PM, Gabriel Dos Reis
>> <gdr at integrable-solutions.net> wrote:
>>> On Sat, May 16, 2009 at 2:58 PM, Juan Jose Garcia-Ripoll
>>> <juanjose.garciaripoll at googlemail.com> wrote:
>>>> On Sat, May 16, 2009 at 3:31 AM, Gabriel Dos Reis
>>>> <gdr at integrable-solutions.net> wrote:
>>>>> This is a functionality, so instead of testing for a specific platform, ECL
>>>>> should be testing for that functionality.  For example, the following
>>>>> Autoconf macro does the work
>>>>>
>>>>>    AC_CHECK_HEADERS([stdint.h inttypes.h])
>>>>
>>>> Autoconf is nice, but it is not the panacea. The reason why we have a
>>>> specific check for sun is that this platform had stdint.h but did not
>>>> provide all integer types
>>>
>>> That is why I also tested for inttypes.h.
>> I forgot to mention that, once you tested for the above two headers,
>> you test for the specific integer types with the two headers included
>>    AC_TYPE_UINT8
>> etc.
>
> Again, I am not opposing a change, but I want you to get a feeling of
> this line of code which is about 10 years old. At the time some

I appreciate that -- even if that may not be apparent from the message.
Ten years ago I was dealing with a piece of
relatively large C software that was written 14 years before in K&R C
and was supposed to compile C, C++, Fortran, Java, etc to native code on a
large array of platforms :-)
(And Autoconf support at that time was relatively immature)

> platforms provided stdint, some provided inttypes, some provided none,
> some provided both of them but incomplete. I think you get the feeling
> of how complicated it gets, very quickly, even with Autoconf's macros.
> What you suggest involves 2 macros for the headers plus one for every
> new type, a total of about 6 macros just for all integer types, plus a
> lot of #ifdefs around. We have now a better (but ugly) approach for
> int16_t that I will generalize for int8_t.

The point wasn't whether it was ugly.  But whether it works on the platforms
that do provide the headers.  I believe ECL should use any approach that is
deemed superior in that it works whenever Autoconf works.  The current
approach does not look it does.  And a characteristic of the problem is that
a solution that lists platforms as opposed to functionality will utimately
fails where the above Autoconf macros work.

The unimpressive array of #ifdefs is annoying, but it does not look like
the implementation language (C) is the only t blame.  It seems that
writing a portable software in a "system" language implies some amount
of that kind of stuff.