Re: Inspirels Ada on cortex tutorial linker issue

[Maciej Sobczak <see.my.homepage@gmail.com>]

> >>  From a practical point of view, configuring a piece of
> >> stereotypical C code means autoc***.
> >
> > Nonsense. I have written
> 
> (So, there exists at least 1 x, therefore all x, in practice? ;-)

No. Rather - therefore there is no such thing as a stereotypical C code.

> How about this explanation of autoconf: people don't understand,
> from a technical point of view, just why they are using autoconf.

I agree with that. I have seen autoconf scripts checking whether there is a Fortran compiler installed, even though the given project was not using Fortran. Or whether there are standard functions. People have been blindly copying autoconf script pieces from each other without trying to understand what they do, only to deteriorate the whole ecosystem with time.
But this is not due to C limitations.
According to Wikipedia (https://en.wikipedia.org/wiki/Autoconf):

"Autoconf is agnostic about the programming languages used [...]"

> The motivation would, I guess, be this: I do just what the others
> usually do,

Which is a property of all things that are popular beyond technical justification. If Ada was as popular as C, you would have hordes of incompetent Ada "coders", too. And autoadaconf, too.

>        The Eleventh Commandment
>     configure, make, make install

Yes. One guy asked me to provide the configure script, because he refused to use a package that did not have it. I have instructed him to create an empty configure script instead.
But I still don't blame the C language for that.

> I claim that at least the stereotypical setup of Ada is better
> in that Ada does try to address some issues at the language level
> like C does to a lesser degree.

OK, so again from the same Wikipedia page:

"GNU Autoconf is a tool for producing configure scripts for building, installing and packaging software on computer systems where a Bourne shell is available."

Let pick the most important parts:
- building
- installing
- packaging

These are the voids that autoconf is (or rather was) trying to fill in the GNU ecosystem. What does Ada offer in these areas?
Let's see:

- Building - nothing. Every compiler vendor has their own, mutually incompatible approach for building programs. It was already pointed here how useful is GNATMake with Janus/Ada, for example.
- Installing - nothing. No, really. Seriously. Nothing.
- Packaging - nothing. Void. Null.

There are further things that you might ask for, like library dependency management utilities, remote repository management tools, etc. The more you ask, the less you will find in the Ada ecosystem.

There are systems like Debian where Ada benefits from the general, system-wide approach for these things (and of course from the voluntary effort of people who are doing the hard work). Thus, I can apt-get install whatever and it will just work. But like it or not, the infrastructure for all these useful tools was founded by those who you detest. It is *not* the Ada's achievement that Ada programs can be built, installed, packaged, downloaded and have their dependencies managed on such systems.

> To achieve C portability and ease
> of change, it takes a lot of knowledge and discipline, and also, typically,
> independent thinking of a courageous individual programmer using C.

Substitute Ada for C in the above and it is still true. Even more so if you take into account how much thinking independence is required to even consider Ada for new projects.

> > If autotools do not work for you, it's not the fault of C
> 
> Are you certain that the definition of C, its means for expressing
> configuration, or variations (#if[def], say, or its type system
> when LSP is desired?) will have no influence on how it is used
> with Make, "discipline", etc? Would it not give rise to autoconf?

I am certain that Ada did not give rise to autoadaconf. Instead, Ada programmers rely on the infrastructure built by C programmers, as explained above.

> So that's one data point I had actually been hoping to see:
> How useful is elaboration, a requirement that Ada does address?

I do not find it to be a critical language feature. Ada *does* have its killer features, but elaboration control is not one of them.
Actually, it is known that depending on the combination of compiler options, it is possible to have a program that will build on one compiler, but not on the other.

-- 
Maciej Sobczak * http://www.inspirel.com