Re: Specifying a target in a GPRBuild project file?

[Georg Bauhaus <rm-host.bauhaus@maps.arcor.de>]

Yannick Duchêne (Hibou57 ) <yannick_duchene@yahoo.fr> wrote:

>> Just imagine some portable combined Ada/C++ program source text that has
>> become the subject of GPRbuild (alternatively, to whatever Atego's
>> Rational thing does, etc). Will porting the Ada/C++ program still be
>> both practical and cost efficient in the presence of having to port
>> one proprietary (open-source) configuration text to another proprietary
>> (maybe-not-open-source) configuration text?
> 
> In this case, just use a classic Makefile and describe in a README file, 
> what may have to be tweaked in it (compiler paths, names, options, etc).

Makefiles do not solve the recurring problem of configuring sets of tools:
When a source text of a mixed Ada and C++ program is perfectly
portable, why is it necessary to have elaborate but incompatible *tool*
configuration texts? Suppose you have successfully tested the
program with the front ends of GCC on some platform. You are now
moving towards a combination of non-GNAT and non-G++ compilers and
tools. As a consequence, you will be spending time and money on 
expressing the very same ideas once more, this time using different
tool configuration languages.

The only profit from having worked on a Makefile or GPR project file is
to have thought about it. If someone knows non-GCC configuration well,
but does not know GCC's configuration mini-languages, he or she will
learn very little from either. Note that he or she does not need to learn
the
subject of configuring tools, they know that. But the lack of a common
configuration language forces them to learn yet another vendor's language
for expressing common ideas.

Doesn't this sound familiar? Expressing formal things in many incompatible
vendor languages?

>> Who is financing this misguided use of brain power that creates
>> monstrosities of configuration to live in a costly zoo?
> 
> There is nothing monstrous with it, it just fix compilers paths and  
> options, and default project files attributes and variables. 

Try porting one so that it can be used from within a very different
toolset for the same purpose.