Specifying a target in a GPRBuild project file?

[Yannick Duchêne (Hibou57)]

Hi people,

According to [1], neither of the `--target` or `--config` options are
allowed in a project file, and these can only be given to GPRBuild via the
command line. That's not that much an issue with the `--config` option, as
this one is better derived from the `--target` option. So I was primarily
wondering if there is a way to specify the target in a project file using
an attribute.

I could not find one in the user guide, but may be I've just missed it. Do
someone know an attribute to achieve this? Or may be a gentle trick? Or
may be that's not feasible because GPRBuild needs to know the project
configuration before starting interpretation of the project file?

[1]: http://docs.adacore.com/gprbuild-docs/html/gprbuild_ug.html


--
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

[Yannick Duchêne (Hibou57)]

Le Tue, 23 Apr 2013 09:46:26 +0200, Yannick Duchêne (Hibou57)
<yannick...@yahoo.fr> a écrit:

> So I was primarily wondering if there is a way to specify the target in
> a project file using an attribute.

Oops, sorry, it was there:

User guide @1.9.10.1 Project Level Attributes
> Target: singleValue is the name of the target platform.

[Yannick Duchêne (Hibou57)]

Le Tue, 23 Apr 2013 10:09:35 +0200, Yannick Duchêne (Hibou57)

<yannick...@yahoo.fr> a écrit:

> Le Tue, 23 Apr 2013 09:46:26 +0200, Yannick Duchêne (Hibou57)
> <yannick...@yahoo.fr> a écrit:
>
>> So I was primarily wondering if there is a way to specify the target in
>> a project file using an attribute.
>
> Oops, sorry, it was there:
>
> User guide @1.9.10.1 Project Level Attributes
>> Target: singleValue is the name of the target platform.

I may be doing something wrong, if some one know how to set it up, here is
how it does not work as expected with me: if I give GPRBuild a `--target`
option, it does not seems to set the project Target attribute (it stays an
empty string); now if I give the project a Target attribute, it does not
make GPRBuild choose the good configuration file.

Seems the `--target` option and the Target attribute are distinct and do
different things. I'm wondering what the Target attribute do finally.

What am I missing?

[Yannick Duchêne (Hibou57)]

Le Tue, 23 Apr 2013 13:37:50 +0200, Yannick Duchêne (Hibou57)
<yannick...@yahoo.fr> a écrit:

> I may be doing something wrong, if some one know how to set it up, here
> is how it does not work as expected with me: if I give GPRBuild a
> `--target` option, it does not seems to set the project Target attribute
> (it stays an empty string); now if I give the project a Target
> attribute, it does not make GPRBuild choose the good configuration file.

I've checked again, and was wrong with the first point, but still OK with
second. The Target attribute really gets initialized with the `--target`
option, but changing the Target attribute does not changed the target.
That's a bit misleading, as this attribute is not said to be read‑only (I
believe it should be).

[Yannick Duchêne (Hibou57)]

Le Tue, 23 Apr 2013 16:04:30 +0200, Yannick Duchêne (Hibou57)
<yannick...@yahoo.fr> a écrit:

> I've checked again, and was wrong with the first point, but still OK
> with second. The Target attribute really gets initialized with the

> `--target` option, […]

Now I see more, and understand why I've seen two different behaviours.
Here is: it's initialized with `--target` for classic project files only,
and it's not initialized with library project files. With library
projects, whatever the `--target` option, the Target attribute will always
be an empty string.

Will drop a mail to AdaCore later (I'm pretty sure that's not the intended
behaviour… too strange).

[sbelm...@gmail.com]

FWIW, I reported that behavior to them some time last year (target attribute within a project file always resolves to a null string), but never got a response.

[Yannick Duchêne (Hibou57)]

Finally, that's not loosing anything: the `--target` option is not safe at
all, using the `--config` option is better. The reason is that with
`--config` you are sure to get what you expect or else an error. With
`--target`, if it does not find the compiler with the default
configuration, you may have an `aut.cgpr` for a different target than the
one specified for the option.

When passing the target to the project file is required, then an external
variable may be used, as with an `-Xtarget=…` option given to GPRBuild.

The `--target` option should only be used with explicit invocations of
GPRConfig, not with GPRBuild.

[Pascal Obry]

Le 25/04/2013 11:01, Yannick Duchêne (Hibou57) a écrit :
> The `--target` option should only be used with explicit invocations of
> GPRConfig, not with GPRBuild.

I fully disagree. I'm building many cross tools and always using
gprbuild --target=xyz. This is the way it should work, and if not
probably a bug to report.

--
Pascal Obry / Magny Les Hameaux (78)

The best way to travel is by means of imagination

http://v2p.fr.eu.org
http://www.obry.net

gpg --keyserver keys.gnupg.net --recv-key F949BD3B

[Dmitry A. Kazakov]

On Thu, 25 Apr 2013 18:57:10 +0200, Pascal Obry wrote:

> Le 25/04/2013 11:01, Yannick Duch�ne (Hibou57) a �crit :

>> The `--target` option should only be used with explicit invocations of
>> GPRConfig, not with GPRBuild.
>
> I fully disagree. I'm building many cross tools and always using
> gprbuild --target=xyz. This is the way it should work, and if not
> probably a bug to report.

For this purpose I am using a scenario variable that controls Compiler,
Linker etc packages. It also manipulates Source_Dirs because different
targets have some source files different (I don't want to use
preprocessor).

I am interested in a comparison of this approach to --target.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

[sbelm...@gmail.com]

On Thursday, April 25, 2013 5:01:32 AM UTC-4, Hibou57 (Yannick Duchêne) wrote:
>
> Finally, that's not loosing anything: the `--target` option is not safe at
>
> all, using the `--config` option is better. The reason is that with
>
> `--config` you are sure to get what you expect or else an error. With
>
> `--target`, if it does not find the compiler with the default
>
> configuration, you may have an `aut.cgpr` for a different target than the
>
> one specified for the option.
>

While I generally agree that using --config is better than --target (we have had situations where installation of a new compiler suddenly becomes the 'default' based on the path order), the fact is that either way there is a 'target' variable defined in the .cgpr, and it ought to be available in the gpr file as project'target. There are plenty of situations where one single gpr should be able to conditionally control the source directories (et al) based on what the target will be.

Its senseless that I have to do something like this:

gprbuild --config=vxworks.cgpr --Xtarget=vxworks project.gpr

when 1.9.10.1 clearly states (under the 'configuration-general heading) that the target attribute "is the name of the target platform", and not always a null. One extra command line argument isn't the end of the world, I guess, but like you said, things should work how they are documented.

-sb

[Stephen Leake]

Pascal Obry <pas...@obry.net> writes:

> Le 25/04/2013 11:01, Yannick Duchêne (Hibou57) a écrit :
>> The `--target` option should only be used with explicit invocations of
>> GPRConfig, not with GPRBuild.
>
> I fully disagree. I'm building many cross tools and always using
> gprbuild --target=xyz. This is the way it should work, and if not
> probably a bug to report.

+1

note that gprbuild will invoke gprconfig if necessary; gprbuild is the
only tool a user needs to invoke directly.

--
-- Stephe

[Pascal Obry]

Le 25/04/2013 21:02, Dmitry A. Kazakov a �crit :

> For this purpose I am using a scenario variable that controls Compiler,
> Linker etc packages. It also manipulates Source_Dirs because different
> targets have some source files different (I don't want to use
> preprocessor).

No scenario variable won't help calling the right tool chain. For
example if you compile a Win32 version of a project from Linux the
proper winres tool will be called:

$ gprbuild --target=i686-pc-mingw32 prj.gpr

And if one of the language is winres then at some point a call to:

$ i686-pc-mingw32-winres ...

will be made.

There is no way to achieve that with scenario variables which are useful
to select proper sources and naming scheme. It is also used to pass the
proper libraries. In fact most of the time I'm using:

$ gprbuild --target=i686-pc-mingw32 -XTARGET=Windows prj.gpr

That is, I teach gprbuild about the cross environment using the proper
triplet name and the project file circuitry about the variant I'm
building. Most of the time the TARGET project variable is UNIX, Darwin
or Windows.

Pascal.

[Yannick Duchêne (Hibou57)]

Le Fri, 26 Apr 2013 11:54:26 +0200, Stephen Leake
<stephe...@stephe-leake.org> a écrit:

GPRBuild invokes GPRConfig, without user interaction and acknowledgement
from the user. If there are multiple compilers on the `$PATH`, the choice
GPRConfig made may not be good. Also, by default GPRBuild invokes
GPRConfig each times, and if something changed in the `$PATH` or in the
installed compilers, the configuration file may change and not for a good
one.

Using a `--config` option is deterministic.

Or else a `--target` option if there is a matching `<target>.cgpr` and it
is found by GPRBuild, but this one is just half deterministic, as if it
don't find a `<target>.cgpr`, it won't complain and will invoke GPRConfig.

I agree with both of you, for the case you have one single compiler, which
is the most typical case. In this case which is simple, that's relevant to
keep it simple.

If there is more than one, an automatic configuration which change each
time is less safe and what's more simple, is an explicit invocation of
GPRConfig, a validation of the configuration file and a re‑use of the same
unchanged configuration file each time.

I could not reproduce the case (I wanted to post an example), but I had a
case of an automatic configuration using a compiler for a non‑matching
target (or there was two compilers for the same target? can't remember
exactly…).

[Yannick Duchêne (Hibou57)]

Le Fri, 26 Apr 2013 18:09:37 +0200, Pascal Obry <pas...@obry.net> a écrit:

> Le 25/04/2013 21:02, Dmitry A. Kazakov a écrit :
>> For this purpose I am using a scenario variable that controls Compiler,
>> Linker etc packages. It also manipulates Source_Dirs because different
>> targets have some source files different (I don't want to use
>> preprocessor).
>
> No scenario variable won't help calling the right tool chain.
>

> […]

>
> There is no way to achieve that with scenario variables which are useful
> to select proper sources and naming scheme. It is also used to pass the
> proper libraries. In fact most of the time I'm using:
>
> $ gprbuild --target=i686-pc-mingw32 -XTARGET=Windows prj.gpr
>

That's what I wanted to suggest to Sbelmont.

[Dmitry A. Kazakov]

On Fri, 26 Apr 2013 18:09:37 +0200, Pascal Obry wrote:

> Le 25/04/2013 21:02, Dmitry A. Kazakov a �crit :
>> For this purpose I am using a scenario variable that controls Compiler,
>> Linker etc packages. It also manipulates Source_Dirs because different
>> targets have some source files different (I don't want to use
>> preprocessor).
>
> No scenario variable won't help calling the right tool chain.

I use a scenario variable Platform to select the compiler, binder, linker,
archiver, whatever needed. E.g.

case Platform is
...
when "x86_vxworks" =>
...
for Gnatlist use "... 586-wrs-vxworks-gnatls";
...

So far it worked OK.

> example if you compile a Win32 version of a project from Linux the
> proper winres tool will be called:

Winres is irrelevant for multiplatform projects, but I suppose there should
be an attribute to set it.

> There is no way to achieve that with scenario variables which are useful
> to select proper sources and naming scheme.

Hmm, why should I care about anything except *.adb and *.ads. The rest is
created as appropriate during project build. Platform variable directs
object, ali, a, out, exe files into separate directories.

> It is also used to pass the
> proper libraries. In fact most of the time I'm using:
>
> $ gprbuild --target=i686-pc-mingw32 -XTARGET=Windows prj.gpr
>
> That is, I teach gprbuild about the cross environment using the proper
> triplet name and the project file circuitry about the variant I'm
> building. Most of the time the TARGET project variable is UNIX, Darwin
> or Windows.

I do this:

gnatmake -Pfoo.gpr -XPlaform=x86_vxworks

Do I correctly understand that "target" requires a configuration project?
Because I use none.

[Pascal Obry]

Le 26/04/2013 20:32, Dmitry A. Kazakov a �crit :

> I use a scenario variable Platform to select the compiler, binder, linker,
> archiver, whatever needed. E.g.
>
> case Platform is
> ...
> when "x86_vxworks" =>
> ...
> for Gnatlist use "... 586-wrs-vxworks-gnatls";
> ...

And here there is zero knowledge about the way the target support the
tools, compiler specific options needed, response file support...

> I do this:
>
> gnatmake -Pfoo.gpr -XPlaform=x86_vxworks
>
> Do I correctly understand that "target" requires a configuration project?
> Because I use none.

Yes and no. I don't see why you are not using:

$ x86-pc-vxworks-gnatmake -Pfoo.gpr

which is somewhat equivalent to:

$ gprbuild --target=x86-pc-vxworks foo.gpr

[sbelm...@gmail.com]

On Friday, April 26, 2013 2:32:31 PM UTC-4, Dmitry A. Kazakov wrote:
>
> Do I correctly understand that "target" requires a configuration project?
>
> Because I use none.
>

You always use a configuration project, either explicitly (i.e. using --config) or implicitly (using --target). The target option just invokes gprconfig, which auto-produces the 'auto.cgpr' based on the language and path values and drops in the current directory.

My point is that any config file, auto.cgpr included, contains a 'target' attribute which is, for all intents and purposes, the same as your external platform variable. You ought to be able to do "case project'Target" instead of "case Platform" and achieve the same result without fussing about with an external variable, except GNAT is broken.

-sb

[Yannick Duchêne (Hibou57)]

Le Fri, 26 Apr 2013 20:32:31 +0200, Dmitry A. Kazakov
<mai...@dmitry-kazakov.de> a écrit:

> I do this:
>
> gnatmake -Pfoo.gpr -XPlaform=x86_vxworks
> Do I correctly understand that "target" requires a configuration project?
> Because I use none.
>

I feel to know GNATMake does not use *.cgpr files. GNATMake and GPRBuild
works a lot differently.

[Dmitry A. Kazakov]

On Fri, 26 Apr 2013 20:52:36 +0200, Pascal Obry wrote:

> Le 26/04/2013 20:32, Dmitry A. Kazakov a �crit :
>> I use a scenario variable Platform to select the compiler, binder, linker,
>> archiver, whatever needed. E.g.
>>
>> case Platform is
>> ...
>> when "x86_vxworks" =>
>> ...
>> for Gnatlist use "... 586-wrs-vxworks-gnatls";
>> ...
>
> And here there is zero knowledge about the way the target support the
> tools, compiler specific options needed, response file support...

Yes, but that would not work anyway. I mean, in any case, I must set
specific options for each platform regardless whatever knowledge gprbuild
may possess.

>> I do this:
>>
>> gnatmake -Pfoo.gpr -XPlaform=x86_vxworks
>>
>> Do I correctly understand that "target" requires a configuration project?
>> Because I use none.
>
> Yes and no. I don't see why you are not using:
>
> $ x86-pc-vxworks-gnatmake -Pfoo.gpr

I use one gnatmake for all targets, which is an advantage when you have to
mount additional tool chain on top of it.

> which is somewhat equivalent to:
>
> $ gprbuild --target=x86-pc-vxworks foo.gpr

Which wonders me how gprbuild might know the target. It should search for
all installed cross compilers. Does it that? How? Which one gets selected?

[Dmitry A. Kazakov]

On Fri, 26 Apr 2013 12:09:53 -0700 (PDT), sbelm...@gmail.com wrote:

> You always use a configuration project, either explicitly (i.e. using
> --config) or implicitly (using --target). The target option just invokes
> gprconfig, which auto-produces the 'auto.cgpr' based on the language and
> path values and drops in the current directory.

I don't use *.cgpr stuff. So far I see no compelling reasons to start using
it. Project files are complicated enough without another layer of tools,
which purpose is unclear to me.

If anything useful could be done automatically, why gnatmake/gnat etc does
not do that already? Maybe because it is not so awfully useful? (:-))

[Pascal Obry]

Dmitry,

> I don't use *.cgpr stuff. So far I see no compelling reasons to start using
> it. Project files are complicated enough without another layer of tools,
> which purpose is unclear to me.

Right, you don't but gprbuild does and this is most of the transparent
to users.

> If anything useful could be done automatically, why gnatmake/gnat etc does
> not do that already? Maybe because it is not so awfully useful? (:-))

Because gnatmake is for Ada only whereas gprbuild supports building
applications with multiple languages. The gprbuild knowledge base is
quite impressive, I don't understand you'll want to *not* benefit from it?

[Pascal Obry]

Le 26/04/2013 21:31, Yannick Duchêne (Hibou57) a écrit :
> I feel to know GNATMake does not use *.cgpr files.

Right.

> GNATMake and GPRBuild works a lot differently.

And right again :)

[Dmitry A. Kazakov]

On Sat, 27 Apr 2013 09:45:01 +0200, Pascal Obry wrote:

>> If anything useful could be done automatically, why gnatmake/gnat etc does
>> not do that already? Maybe because it is not so awfully useful? (:-))
>
> Because gnatmake is for Ada only whereas gprbuild supports building
> applications with multiple languages.

Well, I don't have C sources anyway. Neither I am planing them because like
with winres that would be in evident breach with having it multiplatform.

> The gprbuild knowledge base is
> quite impressive, I don't understand you'll want to *not* benefit from it?

Because I don't know the scope of this "knowledge." I don't know what
exactly it does, by which means and how I can benefit from what it does.
Granted, GPR has numerous issues, but I fail to see if auto config solves
any them.

[Yannick Duchêne (Hibou57)]

Le Sat, 27 Apr 2013 08:05:35 +0200, Dmitry A. Kazakov
<mai...@dmitry-kazakov.de> a écrit:

>> which is somewhat equivalent to:
>>
>> $ gprbuild --target=x86-pc-vxworks foo.gpr
>
> Which wonders me how gprbuild might know the target. It should search for
> all installed cross compilers. Does it that? How? Which one gets
> selected?

It's all about GPRConfig, which is invoked behind the scene (precisely
something I personally prefer to be explicit, and that's why I'm in favour
of an explicit `--config` option… multiple opinions differs on that topic).

All the answers to your question are in section #2 of the GPRBuild User
Guide and in the GPRConfig database.

See: http://docs.adacore.com/gprbuild-docs/html/gprbuild_ug.html#Gprbuild
This will tell you about how GPRBuild and GPRConfig works together.

See: `/usr/share/gprconfig/*.xml`
This will tell you how GPRConfig searchs for compilers and select the
appropriate one. This directory exists only if you have GPRBuild
installed. Note you may also give a `--db` option to GPRBuild, to extend
the database with you own database extension (that's what I do for my
compilers, as the default database only knows about GCC 4.6, while I'm
using GCC 4.8).

[Yannick Duchêne (Hibou57)]

Le Sat, 27 Apr 2013 08:17:57 +0200, Dmitry A. Kazakov
<mai...@dmitry-kazakov.de> a écrit:

> On Fri, 26 Apr 2013 12:09:53 -0700 (PDT), sbelm...@gmail.com wrote:
>
>> You always use a configuration project, either explicitly (i.e. using
>> --config) or implicitly (using --target). The target option just
>> invokes
>> gprconfig, which auto-produces the 'auto.cgpr' based on the language and
>> path values and drops in the current directory.
>
> I don't use *.cgpr stuff. So far I see no compelling reasons to start
> using

That starts to be useful when the build involves multiple languages, like
Ada + C or Ada + Assembly or Ada + XML + automatic source generation or
Ada + C + Resources files (the latter, for Windows). That starts to be
useful also when not only the sources has to be properly configured, but
the compilers, binders and linkers too.

GNATMake can handle Ada sources and nothing else; GPRBuild can handle any
languages during the build process beside of Ada, even custom ones.

[Dmitry A. Kazakov]

On Sat, 27 Apr 2013 10:37:37 +0200, Yannick Duch�ne (Hibou57) wrote:

> See: http://docs.adacore.com/gprbuild-docs/html/gprbuild_ug.html#Gprbuild
> This will tell you about how GPRBuild and GPRConfig works together.

Huh, comparing to GPRBuild user's guide even Ada RM reads like a nursery
rhyme. (:-))

> See: `/usr/share/gprconfig/*.xml`
> This will tell you how GPRConfig searchs for compilers and select the
> appropriate one.

This is what I suspected. I am glad I didn't step in it.

[Georg Bauhaus]

On 27.04.13 10:48, Dmitry A. Kazakov wrote:
> On Sat, 27 Apr 2013 10:37:37 +0200, Yannick Duch�ne (Hibou57) wrote:
>
>> See: http://docs.adacore.com/gprbuild-docs/html/gprbuild_ug.html#Gprbuild
>> This will tell you about how GPRBuild and GPRConfig works together.
>
> Huh, comparing to GPRBuild user's guide even Ada RM reads like a nursery
> rhyme. (:-))
>
>> See: `/usr/share/gprconfig/*.xml`
>> This will tell you how GPRConfig searchs for compilers and select the
>> appropriate one.
>
> This is what I suspected. I am glad I didn't step in it.

Anyone who does not need to specialize in configuration business is
a happy person.

Alas, the evolution of configuration tools such as GPRsomething
ultimately develops symptoms and patterns of sophistication that
predictably culminate in some equivalence class of autoconf,
even if you wanted to attribute higher levels of "engineering".

The result: If you are not a member of the current in-group of
conf-savvy consultants, dont't configure. Instead, chose systems that
make the default configurations work. GTD here translates directly
into anti-configurability. Programs are again less portable than
need be:

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?

The acceptance of this hodgepodge is a little puzzling as configuration
business is so akin to programming, and systematic programming at that!

Looking over language borders, after Maven had taken over the "lower level"
configuration solutions for Java software, it was later taken over by
2nd level configuration tools that will control the 1st level Maven.
Programmers may specialize in teaching these tools, or at least learn
how to use them. This works for a few years or so, until the next fashion
does it a little differently.

Who is financing this misguided use of brain power that creates
monstrosities of configuration to live in a costly zoo?

[Yannick Duchêne (Hibou57)]

Le Sat, 27 Apr 2013 15:32:11 +0200, Georg Bauhaus
<rm.dash...@futureapps.de> a écrit:

> Anyone who does not need to specialize in configuration business is
> a happy person.
>
> Alas, the evolution of configuration tools such as GPRsomething
> ultimately develops symptoms and patterns of sophistication that
> predictably culminate in some equivalence class of autoconf,

Actually, GPRBuild is a generalisation of GNATMake, and is not required if
you only use Ada and a single compiler. In the latter case, GNATMake is
enough. The core remains the project file, and the project file is common
to both. So if GPRBuild tends to be a kind of AutoConf, that could be said
of GNATMake too.

> 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).

> 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. That's just
like binding and interfacing. The issue may be when it does not behave as
expected, but that can be said of the compiler too (I personally have more
blocking issues with GNAT bug boxes than with GPRBuild which never been
blocking to me).

[Georg Bauhaus]

Yannick Duchêne (Hibou57 ) <yannick...@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.

[Simon Wright]

"Yannick Duchêne (Hibou57)" <yannick...@yahoo.fr> writes:

> Actually, GPRBuild is a generalisation of GNATMake, and is not
> required if you only use Ada and a single compiler.

Gnatmake won't build shared libraries properly on Mac OS X.

[Yannick Duchêne (Hibou57)]

(That's me who underlined in the quote below)
Le Sat, 27 Apr 2013 20:30:00 +0200, Georg Bauhaus
<rm-host...@maps.arcor.de> a écrit:

> 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.

(deep breath) I fully agree with you about the lack of a standard here.
The actual state is more Bazaar than Cathedral. I wish there was something
common here, but there is not, and you have to do with it and have to
choose either GPRBuild, CMake, Scons or Makefile. By the way, that's not
an issue only with configuration files, but with near to all software in
the large: near to each is designed as if it was the centre of the world
and was alone in the world (I have so much complaint about it I prefer to
not tell more).

[Stephen Leake]

"Yannick Duchêne (Hibou57)" <yannick...@yahoo.fr> writes:

> Le Fri, 26 Apr 2013 11:54:26 +0200, Stephen Leake
> <stephe...@stephe-leake.org> a écrit:
>
>> Pascal Obry <pas...@obry.net> writes:
>>
>>> Le 25/04/2013 11:01, Yannick Duchêne (Hibou57) a écrit :
>>>> The `--target` option should only be used with explicit invocations of
>>>> GPRConfig, not with GPRBuild.
>>>
>>> I fully disagree. I'm building many cross tools and always using
>>> gprbuild --target=xyz. This is the way it should work, and if not
>>> probably a bug to report.
>>
>> +1
>>
>> note that gprbuild will invoke gprconfig if necessary; gprbuild is the
>> only tool a user needs to invoke directly.
>>
>
> GPRBuild invokes GPRConfig, without user interaction and
> acknowledgement from the user. If there are multiple compilers on the
> $PATH`, the choice GPRConfig made may not be good.

The user sets PATH, so that's your user input. I reset PATH for each
project, so there is only one Ada compiler visible.

> Also, by default
> GPRBuild invokes GPRConfig each times,

Not with the correct options:

gprbuild -p --autoconf=obj/auto.cgpr --target=x86-windows -P opentoken.gpr wisi-generate

> and if something changed in the $PATH` or in the installed compilers,
> the configuration file may change and not for a good one.

Sure, if you change things, things change! you must have complete
control of the compilation environment. That's what makefiles are for.

> Or else a `--target` option if there is a matching `<target>.cgpr` and
> it is found by GPRBuild, but this one is just half deterministic, as
> if it don't find a `<target>.cgpr`, it won't complain and will invoke
> GPRConfig.

I agree that's a bug.

--
-- Stephe

[Gour]

On Sat, 27 Apr 2013 23:20:58 +0200
Yannick Duchêne (Hibou57) <yannick...@yahoo.fr> wrote:

> (deep breath) I fully agree with you about the lack of a standard
> here. The actual state is more Bazaar than Cathedral. I wish there
> was something common here, but there is not, and you have to do with
> it and have to choose either GPRBuild, CMake, Scons or Makefile.

I'd have need to work on Ada project including 3rd party C lib which has to be
built and then generate Ada bindings for it as well as the rest of the project
with different pacakges written in Ada as well as main GUI part(gtkada or
qtada). Moreover, I'd lik to provide end-user docs in HTML/PDF format
(probably based on reST/Sphinx).

Can GPRBuild handle all these or is there Ada support in CMake and Scons?

Afaict, there was some attempt to add it for Scons...


Sincerely,
Gour

--
A person who is not disturbed by the incessant flow of
desires — that enter like rivers into the ocean, which is
ever being filled but is always still — can alone achieve
peace, and not the man who strives to satisfy such desires.

[Simon Wright]

"Yannick Duchêne (Hibou57)" <yannick...@yahoo.fr> writes:

> have to choose either GPRBuild, CMake, Scons or Makefile.

I think this is an open set! Ant, for example.

I came across a large example where many hundreds of C and Ada source
files in many directories were built using many C shell scripts.

I talked to the manager concerned, and he sighed that the person
responsible for this had made it his life's work .. a job for life, more
like!

[Dmitry A. Kazakov]

On Sun, 28 Apr 2013 08:47:08 +0200, Gour wrote:

> On Sat, 27 Apr 2013 23:20:58 +0200
> Yannick Duch�ne (Hibou57) <yannick...@yahoo.fr> wrote:
>
>> (deep breath) I fully agree with you about the lack of a standard
>> here. The actual state is more Bazaar than Cathedral. I wish there
>> was something common here, but there is not, and you have to do with
>> it and have to choose either GPRBuild, CMake, Scons or Makefile.
>
> I'd have need to work on Ada project including 3rd party C lib which has to be
> built and then generate Ada bindings for it as well as the rest of the project
> with different pacakges written in Ada as well as main GUI part(gtkada or
> qtada).

3rd party means that other people are to build the library. I don't trust
generated bundings except for very simple cases.

Anyway, the best way to manage C libraries is to define an externally built
library project and forget about the mess. Gnatmake will do the rest. No C
source code in the project.

[Gour]

On Sun, 28 Apr 2013 10:11:25 +0200
"Dmitry A. Kazakov" <mai...@dmitry-kazakov.de> wrote:

> 3rd party means that other people are to build the library.

Well, Debian & Ubuntu have the required library/package, but it's not in e.g.
Fedora, that's why I considered to include sources.

> I don't trust generated bundings except for very simple cases.

I agree and plan to provide thick bindings more suitable for Ada.

> Anyway, the best way to manage C libraries is to define an externally built
> library project and forget about the mess.

Ok. Thank you for the input.

> Gnatmake will do the rest. No C source code in the project.

You don't recommend GPRbuild?


Sincerely,
Gour


--
Before giving up this present body, if one is able to tolerate
the urges of the material senses and check the force of desire and
anger, he is well situated and is happy in this world.

[Dmitry A. Kazakov]

On Sun, 28 Apr 2013 14:56:38 +0200, Gour wrote:

> You don't recommend GPRbuild?

If you have it, you can use it, that would do no difference.

The only problem with GPRbuild is availability of.

[Simon Wright]

"Dmitry A. Kazakov" <mai...@dmitry-kazakov.de> writes:

> On Sun, 28 Apr 2013 14:56:38 +0200, Gour wrote:
>
>> You don't recommend GPRbuild?
>
> If you have it, you can use it, that would do no difference.
>
> The only problem with GPRbuild is availability of.

Not difficult to build GPRbuild GPL 2012 from sources - for a native
compiler, anyway (it requires XML/Ada, also available via GPL 2012).

[Gour]

On Sun, 28 Apr 2013 16:52:17 +0200

"Dmitry A. Kazakov" <mai...@dmitry-kazakov.de> wrote:

> If you have it, you can use it, that would do no difference.

OK.

> The only problem with GPRbuild is availability of.

If that's the only problem, then I don't have it. ;)


Sincerely,
Gour


--
From wherever the mind wanders due to its flickering and unsteady
nature, one must certainly withdraw it and bring it back under
the control of the self.

http://www.atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810