From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: "G.B." Newsgroups: comp.lang.ada Subject: Re: Inspirels Ada on cortex tutorial linker issue Date: Sat, 3 Sep 2016 11:20:04 +0200 Organization: A noiseless patient Spider Message-ID: References: <24d4ffc3-3915-4102-96ae-68d11d881443@googlegroups.com> <2efe4d01-4cd4-4aea-bc54-98ea5f26ec8a@googlegroups.com> <2cf07aa6-9cbb-44bc-8042-601c57c85457@googlegroups.com> <328fa4a3-6215-4101-835a-7eaf7ed72a8c@googlegroups.com> <1d62cc93-324a-4c87-b9d3-67c24cb54c5f@googlegroups.com> <114c0223-e914-4a5c-b533-d1b924895181@googlegroups.com> <9ee99ad0-2fc5-47d3-bd2e-6f418f23a46a@googlegroups.com> <91322cd6-710a-424c-851e-9b5eb013e8a1@googlegroups.com> Reply-To: nonlegitur@futureapps.de Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Sat, 3 Sep 2016 09:20:05 -0000 (UTC) Injection-Info: mx02.eternal-september.org; posting-host="5f926e942a01f530b40cd489ba3662b5"; logging-data="30467"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19faIhqdcGaOe6IbWBrgy8NMK5yumWHqB0=" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 In-Reply-To: Cancel-Lock: sha1:APIJrKUA/3ZnLxNUGz8fa/uNgJA= Xref: news.eternal-september.org comp.lang.ada:31694 Date: 2016-09-03T11:20:04+02:00 List-Id: On 02.09.16 23:33, Maciej Sobczak wrote: > >> 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? ;-) By "practical" I wasn't thinking of how one specific practitioner could make use of C, that wasn't very clear. I was thinking of C programs presenting themselves to any evaluation that tries to assess porting efforts required. > C and C++ code for multiple platforms and have never used autoconf I applaud that. > In fact, I have never understood, actually, why people are using > it at all. How about this explanation of autoconf: people don't understand, from a technical point of view, just why they are using autoconf. The motivation would, I guess, be this: I do just what the others usually do, The Eleventh Commandment configure, make, make install Crowd orientation is a (statistically) very normal trait of programmer behavior, including (program) managerial decisions as to what a distributed product should include (autoconf; what the others do). Come to that, also as to what languages one should use, and how. > So you are having problems with a tool that you associate with some programming language by means of stereotypical relations and you claim what exactly? 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. 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. It does _not_ require autoconf, but this fact is ignored by many. >> They seem to >> be using it > > Who is "they"? The C language standard does not mention them. > Don't blame the language for something that exists outside of it. I do (pompously) blame language efforts for what they leave out (or keep). If it is true that very many C programmers want some portability (witness, e.g., autoconf), how could it not be the business of the language's standardization process to address this common need, and instead shrug and have programmers continue to use autoconf? Programmers want to express something, and they use language for that. > 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? A configuration talks about source text. Therefore, the vocabulary of source text is also present in configuration talk and perhaps vice versa. So, there is a language level, and the language will affect configuration. >> OTOH, if ever there have been standardized Ada build systems, > > Good point. Ada does not even have a consistent convention for naming its source files. With consistency being a good thing, no language should depend on accidentals of operating systems. Neither C nor Ada nor C++ do that(*). However, "language environments" must help programmers getting their compilation units compiled, this much is clear from economy 101, customer's point of view. By extension of economy 101, portability is required between "language environments". But you know what they say about customers. >> Isn't this helpful when solving >> certain problems of order, and of timing, when part A of a program >> needs part B of the program to be in a ready state? >> How would you do the same using C with Make, and formally so? > > When I need (...) at the level of complexity that is actually > interesting in real-life applications. So that's one data point I had actually been hoping to see: How useful is elaboration, a requirement that Ada does address? __ (*) Well, C has its source files and associated scope rules, but I can #include "slarti.bart.fast", and I need to put "body" definitions in conventional "SomeTemplate.hpp", IINM. -- "HOTDOGS ARE NOT BOOKMARKS" Springfield Elementary teaching staff