AdaCore has introduced a patch in FSF GCC to remove ASIS support.

AdaCore is free to do what they want with their own version of GCC.
However, removing a useful feature from the FSF version with the goal to
promote their own, in-house tool is clearly against the spirit of free
software.

Does anybody know the procedures set by the FSF to challenge a patch?

--
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52
https://www.adalog.fr

Le 27/09/2021 à 12:06, J-P. Rosen a écrit :
> AdaCore has introduced a patch in FSF GCC to remove ASIS support.

This is all the more surprising since it seems to me that ASIS is still
in GNAT Pro. What a lack of fairness.

> Does anybody know the procedures set by the FSF to challenge a patch?

unfortunately no

"J-P. Rosen" <rosen@adalog.fr> writes:

> AdaCore has introduced a patch in FSF GCC to remove ASIS support.
>
> AdaCore is free to do what they want with their own version of
> GCC. However, removing a useful feature from the FSF version with the
> goal to promote their own, in-house tool is clearly against the spirit
> of free software.
>
> Does anybody know the procedures set by the FSF to challenge a patch?

It's not just the patch(es), it's any subsequent changes to affected
parts of the compiler.

Le 27/09/2021 à 13:23, Stéphane Rivière a écrit :
> Le 27/09/2021 à 12:06, J-P. Rosen a écrit :
>> AdaCore has introduced a patch in FSF GCC to remove ASIS support.
>
> This is all the more surprising since it seems to me that ASIS is still
> in GNAT Pro. What a lack of fairness.
>
ASIS is no more in the mainstream gcc, it's in a special version, forked
from the main branch, called asis-gcc.

See the instructions on running AdaControl for details:
https://www.adacontrol.fr

--
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52
https://www.adalog.fr

Le 27/09/2021 à 14:48, Simon Wright a écrit :
> "J-P. Rosen" <rosen@adalog.fr> writes:
>
>> AdaCore has introduced a patch in FSF GCC to remove ASIS support.
>>
>> AdaCore is free to do what they want with their own version of
>> GCC. However, removing a useful feature from the FSF version with the
>> goal to promote their own, in-house tool is clearly against the spirit
>> of free software.
>>
>> Does anybody know the procedures set by the FSF to challenge a patch?
>
> It's not just the patch(es), it's any subsequent changes to affected
> parts of the compiler.
>
Right, if they want to contribute further patches, they'll have to keep
it ASIS compatible. That's not a reason to divert gcc to support their
own private interest.

--
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52
https://www.adalog.fr

I must admit I fail to see your point in this thread: as far as I know, ASIS has never worked for recent versions of the language (standard was never updated), and AdaCore doesn't not evolve it anymore.
Yes, that unfortunately means that tools like AdaControl will stop working at some point (you can certainly distribute prebuilt binaries for a while, but for anyone using new language constructs, what happens ?).
This being open-source software, you could adopt the maintenance of ASIS yourself (or ask other people in the Ada community to help with that). But this is of course a significant endeavor (then again, if you are not ready to do that yourself, why would you expect a commercial company like AdaCore to do it on your behalf ?)

ASIS has not disappeared. It is still (and forever) in the history of the gcc tree. It is just not available on the main branch anymore because there are no more maintainers for it. Just like a lot of obsolete platforms no longer supported by gcc itself, or by the linux kernel for instance. This is the way open-source software lives and dies.

Going to back to a more technical discussion, would you highlight why a library like libadalang is not appropriate for AdaControl. I have developed a few code-generation tools based on it. To me, the main issue is the bad documentation, which leaves a lot of trial-and-error to find which nodes are relevant when. Besides that, it seems to be fine with any code I have sent its way.
Maybe, rather than trying to maintain your own ASIS patches, it would be nice to develop an ASIS API that uses libadalang underneath (I do not know much about ASIS to be honest, so this might be a stupid suggestion).

Emmanuel

On Monday, September 27, 2021 at 1:23:39 PM UTC+2, Stéphane Rivière wrote:
> Le 27/09/2021 à 12:06, J-P. Rosen a écrit :
> > AdaCore has introduced a patch in FSF GCC to remove ASIS support.
> This is all the more surprising since it seems to me that ASIS is still
> in GNAT Pro. What a lack of fairness.

We have removed ASIS support first in our own trunk of GNAT, and then 6 months later we have removed it from the GCC FSF trunk, so talking about lack of fairness is, well, unfair.

Why? Because ASIS is no longer maintained as an internal standard and hasn't evolved beyond Ada 95 because there was not enough support in the community and among vendors, so we've ended up maintaining it on our own for many years, which lately has become too large a burden. In addition, maintaining ASIS tree generation in GNAT has been also a challenge and a resource drain because each time we make a change in the GNAT front-end, this may break ASIS and we may have to make difficult investigation and changes and sometimes almost impossible changes because there are conflicts between the need of a code generator (GNAT for GCC or LLVM) and the need of an Ada analysis library (ASIS).

So we've decided to address this burden by moving tree generation for ASIS in a separate branch, so that this maintenance burden on GCC trunk would disappear.

This has been done both in AdaCore's tree where ASIS now resides on a separate branch, and in GCC FSF where the tree generation is available in GCC 10..x and works well here, and is available for the community to contribute and maintain for as long as needed.

Arno

On 27/09/2021 14:20, J-P. Rosen wrote:
> Le 27/09/2021 à 14:48, Simon Wright a écrit :
>> "J-P. Rosen" <rosen@adalog.fr> writes:
>>
>>> AdaCore has introduced a patch in FSF GCC to remove ASIS support.
>>>
>>> AdaCore is free to do what they want with their own version of
>>> GCC. However, removing a useful feature from the FSF version with the
>>> goal to promote their own, in-house tool is clearly against the spirit
>>> of free software.
>>>
>>> Does anybody know the procedures set by the FSF to challenge a patch?
>>
>> It's not just the patch(es), it's any subsequent changes to affected
>> parts of the compiler.
>>
> Right, if they want to contribute further patches, they'll have to keep
> it ASIS compatible. That's not a reason to divert gcc to support their
> own private interest.

Why is this at all surprising? AdaCore was created off the backs of U.S.
taxpayers via grants Robert Dewar used to fund development of GNAT.

https://en.wikipedia.org/wiki/GNAT
https://en.wikipedia.org/wiki/Robert_Dewar

This has been a questionable racket from Day 1.

Hey look, trolling from an anonymous guys... We haven't see that in a while.

nobody in particular <nobody@devnull.org> writes:

> Why is this at all surprising? AdaCore was created off the backs of
> U.S. taxpayers via grants Robert Dewar used to fund development of
> GNAT.
>
> https://en.wikipedia.org/wiki/GNAT
> https://en.wikipedia.org/wiki/Robert_Dewar
>
> This has been a questionable racket from Day 1.

(a) Boeing
(b) :plonk:

On 29/09/2021 11:03, Simon Wright wrote:
> nobody in particular <nobody@devnull.org> writes:
>
>> Why is this at all surprising? AdaCore was created off the backs of
>> U.S. taxpayers via grants Robert Dewar used to fund development of
>> GNAT.
>>
>> https://en.wikipedia.org/wiki/GNAT
>> https://en.wikipedia.org/wiki/Robert_Dewar
>>
>> This has been a questionable racket from Day 1.
>
> (a) Boeing
> (b) :plonk:
>

Que?

"Luke A. Guest" <laguest@archeia.com> writes:

> On 29/09/2021 11:03, Simon Wright wrote:
>> nobody in particular <nobody@devnull.org> writes:
>>
>>> Why is this at all surprising? AdaCore was created off the backs of
>>> U.S. taxpayers via grants Robert Dewar used to fund development of
>>> GNAT.
>>>
>>> https://en.wikipedia.org/wiki/GNAT
>>> https://en.wikipedia.org/wiki/Robert_Dewar
>>>
>>> This has been a questionable racket from Day 1.
>> (a) Boeing
>> (b) :plonk:
>>
>
> Que?

Boeing's development of commercial airliners has had massive (indirect)
subsidy from the defence budget.

> We have removed ASIS support first in our own trunk of GNAT, and then 6 months later we have removed it from the GCC FSF trunk, so talking about lack of fairness is, well, unfair.

I deeply endorse your maintenance and code evolution concerns.

The lack of 'fairness' (my apologies if you find that word a bit strong)
is that GNAT pro users are suddenly the only ones who can use ASIS,
while a unique tool like Adacontrol (for code control quality) has
always been available equally to the Free and Pro communities...

> Why? Because ASIS is no longer maintained as an internal standard and hasn't evolved beyond Ada 95 because there was not enough support in the community and among

Thanks Arno for these explanations...

We all know about Adacore's commitment to the Free Software community.
The latest versions of GNATStudio, which has never been so reliable and
user-friendly, are just one example among others.

However, the initial problem persists and cannot be solved quickly.

Should Adacontrol users find a relationship using GNAT-Pro to release
the tools needed to continue using Adacontrol?

Maybe Adacore could reconsider its decision to keep ASIS for the Pro
community only and release it again, at least temporarily, to give the
Libre community some time to find a sustainable solution?

This could be an intermediate solution, pending a possible port of
Adacontrol to libadalang (or any other satisfying way).

Perhaps Adacore could help the community and Jean-Pierre in this
process? (targeted help, improved documentation, etc.)?

Thanks again for participating in this thread. It is very interesting to
talk with a representative of the most essential Ada contributor to
Libre software.

Stéphane

On Monday, September 27, 2021 at 9:20:04 AM UTC-5, J-P. Rosen wrote:
> Le 27/09/2021 à 14:48, Simon Wright a écrit :
> > "J-P. Rosen" <ro...@adalog.fr> writes:
> >
> >> AdaCore has introduced a patch in FSF GCC to remove ASIS support.
> >>
> >> AdaCore is free to do what they want with their own version of
> >> GCC. However, removing a useful feature from the FSF version with the
> >> goal to promote their own, in-house tool is clearly against the spirit
> >> of free software.
> >>
> >> Does anybody know the procedures set by the FSF to challenge a patch?
> >
> > It's not just the patch(es), it's any subsequent changes to affected
> > parts of the compiler.
> >
> Right, if they want to contribute further patches, they'll have to keep
> it ASIS compatible. That's not a reason to divert gcc to support their
> own private interest.
> --
> J-P. Rosen
> Adalog
> 2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
> Tel: +33 1 45 29 21 52
> https://www.adalog.fr

There does seemingly exist a way to directly compete against AdaCore's increasing proprietarization of GNAT to herd Ada users into GNAT Pro licenses as a higher-revenue way of what was supposed (back in the 1990s) to have been a business model for charging only for •support• of free open-source software (spelled out instead of FOSS to emphasize free and openness of open source). Because neither FSF's GNAT nor FSF's GNAT Runtime Library are licensed under the GNU Affero Public License (GAPL), it seems that it would be possible to both 1) execute GPL-licensed proprietary-extended FSF GNAT in the cloud and then 2) link against the Runtime-Library-Exception(RLE)-licensed FSF-GNAT's runtime library in the cloud without divulging the source code to the proprietary extensions to GNAT, as long as the copy of the GNAT compiler that resides on VM instances in the cloud cannot be downloaded or distributed. Then the R&D effort needed to extend GNAT in these proprietary ways would presumably (under regular GPL) not need to contributed back to AdaCore, because no distribution occurred, hence complete compliance (I suspect) with the terms of GPLv3. As I understand it, this would change radically if AdaCore were to somehow switch FSF GNAT's licensing over to the Affero license.

But until AdaCore (with GNU Foundation's blessing) would switch FSF GNAT to Affero license, for a third-party company who is aggrieved at the loss of ASIS and its supporting constructs within GNAT, that aggrieved company could conceivably raise funds to perform the expensive R&D to put ASIS back into a cloud-only proprietary-extension version of the GNAT compiler without giving their hard work away to AdaCore. Hence, that aggrieved company could conceivably attract investors to the aggrieved company's business model by having a barrier-to-entry-fortified value proposition in the cloud-only proprietary-extension version of the GNAT compiler.

Yes, of course, the downside would be that every compilation via the cloud-only proprietary-extension version of the GNAT compiler would need an extant working Internet connection—no offline compilation capability in this alternate version of GNAT. And yes, of course, this would raise the ire of both AdaCore and GNU Foundation, who could then switch over to the Affero license for FSF GNAT, or even author some GPLv4 to address this loophole. And yes, of course, porting* any ASIS software to RLEv3.1-licensed libadalang would be fraught with far fewer legal complications, and in fact might be less software-development effort as well.

* Porting here of course means practically rewriting from scratch, which is not the usual definition of “porting”.

The posting above is merely a record of my personal musings. I am not a lawyer. I haven't passed any bar exam nor been admitted to any bar in any jurisdiction nor have any license to practice law. The letter & interpretation of copyright law might very well vary in your government's jurisdiction. But even with the aid of an attorney, only you can form your own understanding of GPLv3 and GAPLv3; your understanding might reach different conclusions than anything indicated in this amateur posting.

> The lack of 'fairness' (my apologies if you find that word a bit strong)
> is that GNAT pro users are suddenly the only ones who can use ASIS,
> while a unique tool like Adacontrol (for code control quality) has
> always been available equally to the Free and Pro communities...

I might have misunderstood Arno's point, but my understanding is that AdaCore no longer makes any patch for ASIS.
So whatever pro customers have access to (and ASIS was always a paying addon), the community also has access to by downloading the latest available sources.

The GNAT Pro compiler apparently is losing the capability to generate the tree information, just like the free version of the compiler.
If you want to use ASIS, my understanding is that you would have to do a separate "compilation" pass using the compiler from the dedicated branch just for the purpose of generating the tree files (and you can discard all the object files it perhaps generates at the same time). Then you can run ASIS tools.

This is for sure a pain for AdaControl maintainers and users, no one disputes that. On the other hand, if tree generation was indeed getting in the way of compiler improvements that benefit every one, I, for one, am happy to see the change.

> Perhaps Adacore could help the community and Jean-Pierre in this
> process? (targeted help, improved documentation, etc.)?

I suggested in an early message that perhaps the community could build an ASIS API on top of libadalang, if there is a need for that.
I also suggested that libadalang documentation should be improved, I definitely agree with that one !

On 29/09/2021 20:04, Emmanuel Briot wrote:

> I suggested in an early message that perhaps the community could build an ASIS API on top of libadalang, if there is a need for that.
> I also suggested that libadalang documentation should be improved, I definitely agree with that one !
>

Freely available iso asis spec would help here.

Le 28/09/2021 à 09:38, Arnaud Charlet a écrit :
> We have removed ASIS support first in our own trunk of GNAT, and then
> 6 months later we have removed it from the GCC FSF trunk, so talking
> about lack of fairness is, well, unfair.It is unfair because asis-gcc is not distributed to the community

> Why? Because ASIS is no longer maintained as an internal standard and
> hasn't evolved beyond Ada 95 because there was not enough support in
> the community and among vendors,
The ASIS standard has not been updated, but AdaCore did a great job of
evolving its ASIS implementation to support all new features up to
Ada2012. It would be easy to add these improvements to a revised ASIS
standard, and a New Work Item will be proposed to ISO to that effect.

Anyway, this issue of ASIS not being an up-to-date standard is a red
herring, since LibAdalang is NOT a standard, and presumably never will.

> so we've ended up maintaining it on our own for many years, which
> lately has become too large a burden.This is plain wrong. You don't maintain ASIS "on your own", there are
customers who pay a support contract for ASIS.

> In addition, maintaining ASIS tree generation in GNAT has been also a
> challenge and a resource drain because each time we make a change in
> the GNAT front-end, this may break ASIS and we may have to make
> difficult investigation and changes and sometimes almost impossible
> changes because there are conflicts between the need of a code
> generator (GNAT for GCC or LLVM) and the need of an Ada analysis
> library (ASIS).
>
> So we've decided to address this burden by moving tree generation for
> ASIS in a separate branch, so that this maintenance burden on GCC
> trunk would disappear.
We are talking about FSF-GNAT here. AFAIK, asis-gcc has not been pushed
to FSF-GNAT.

> This has been done both in AdaCore's tree where ASIS now resides on a
> separate branch, and in GCC FSF where the tree generation is
> available in GCC 10.x and works well here, and is available for the
> community to contribute and maintain for as long as needed.
>
But this means that users of ASIS will be stuck to GCC 10.x, or will
have to handle two versions of gcc at the same time, which is an endless
source of burden. Why don't you make asis-gcc available to the
community? It doesn't require any extra cost, since it is available to
paying customers!

Anyway, my question was about how to challenge a patch. I estimate that
this patch is unfortunate, you argue that it is necessary. Let the GCC
governance decide; AdaCore doesn't rule GCC.

--
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52
https://www.adalog.fr

Le 29/09/2021 à 21:04, Emmanuel Briot a écrit :

> I might have misunderstood Arno's point, but my understanding is that AdaCore no longer makes any patch for ASIS.
No, ASIS is still maintained (although as LTM) for paying customers.

> So whatever pro customers have access to (and ASIS was always a paying addon), the community also has access to by downloading the latest available sources.
No, asis-gcc is not distributed by AdaCore.

> The GNAT Pro compiler apparently is losing the capability to generate the tree information, just like the free version of the compiler.
> If you want to use ASIS, my understanding is that you would have to do a separate "compilation" pass using the compiler from the dedicated branch just for the purpose of generating the tree files (and you can discard all the object files it perhaps generates at the same time). Then you can run ASIS tools.
Not really. Compile-on-the-fly is still working with asis-gcc
(AdaControl is working like that).

> This is for sure a pain for AdaControl maintainers and users, no one disputes that. On the other hand, if tree generation was indeed getting in the way of compiler improvements that benefit every one, I, for one, am happy to see the change.
I'm afraid this is a red herring. I think rather that AdaCore has a hard
time convincing people of moving from the well defined, carefully
designed ASIS to the terrible mess of LibAdalang.

To anybody interested in that issue: don't take my word for it. Please
read the specification of any ASIS module, and compare it to
libadalang.analysis package.

Personnaly, I will never trust an interface that documents that I should
expect a character literal on the LHS of an assignment statement!

Another example: it's only very recently (not sure if it is already in
GitHub) that LibAdalang considered the case of a variable declaration
with multiple names. How do you explain such an omission after 5 years
of development?

>> Perhaps Adacore could help the community and Jean-Pierre in this
>> process? (targeted help, improved documentation, etc.)?
>
I have had a tool partner's agreement with AdaCore, and until recently
they have been very helpful. But the whole design of LibAdalang is not
appropriate for deep static analysis, and it is an error to believe that
it could replace ASIS. OTOH, it has plenty of useful features for other
use cases not covered by ASIS, like handling of incomplete/incorrect
code, no question about that.

> I suggested in an early message that perhaps the community could build an ASIS API on top of libadalang, if there is a need for that.
In the beginning of LibAdalang, AdaCore suggested doing that, but they
abandonned it.

> I also suggested that libadalang documentation should be improved, I definitely agree with that one !
>
Unfortunately, the whole design (and especially the typing system) of
Libadalang makes it much more difficult to use than ASIS.

--
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52
https://www.adalog.fr

Le 30/09/2021 à 01:29, Luke A. Guest a écrit :
>
> On 29/09/2021 20:04, Emmanuel Briot wrote:
>
>> I suggested in an early message that perhaps the community could build
>> an ASIS API on top of libadalang, if there is a need for that.
>> I also suggested that libadalang documentation should be improved, I
>> definitely agree with that one !
>>
>
> Freely available iso asis spec would help here.
Actually, it is. Apart from ISO verbiage, all the interesting parts of
the ASIS standard is put as comments in the corresponding ASIS packages.

Moreover, AdaCore kept this good habit for all the newly introduced
features that support up to Ada 2012, which would make retrofitting them
into an updated ASIS standard quite easy.

--
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52
https://www.adalog.fr

Le 28/09/2021 à 08:55, Emmanuel Briot a écrit :
> I must admit I fail to see your point in this thread: as far as I know, ASIS has never worked for recent versions of the language (standard was never updated), and AdaCore doesn't not evolve it anymore.
Your information is not up-to-date. AdaCore has evolved its ASIS
implementation to fully support up to Ada 2012, and there will be a
proposal to renew the ASIS standard at ISO.

Claiming that ASIS is obsolete and has not evolved since 95 is pure FUD
propagated by AdaCore. Anybody can download AdaCore's latest
implementation and check that Ada 2012 is fully supported.

> Yes, that unfortunately means that tools like AdaControl will stop working at some point (you can certainly distribute prebuilt binaries for a while, but for anyone using new language constructs, what happens ?).
AdaControl fully supports Ada 2012. Many new features of Ada 202x use
aspects, which are fully supported. The main syntactic addition is the
"parallel" constructs, but few people will need it, and AdaCore said
once that they would not support it.

> This being open-source software, you could adopt the maintenance of ASIS yourself (or ask other people in the Ada community to help with that). But this is of course a significant endeavor (then again, if you are not ready to do that yourself, why would you expect a commercial company like AdaCore to do it on your behalf ?)
Because that commercial company has customers who pay for that.

[...]

> Going to back to a more technical discussion, would you highlight why a library like libadalang is not appropriate for AdaControl. I have developed a few code-generation tools based on it. To me, the main issue is the bad documentation, which leaves a lot of trial-and-error to find which nodes are relevant when. Besides that, it seems to be fine with any code I have sent its way.
1) the typing system. Yes, the typing system of ASIS is surprising at
first sight, but extremely convenient to use. I suspect that the
designers of LibAdalang never studied the rationale behind ASIS choices
when they decided to make that huge hierarchy of tagged types that
brings no more static checks (you still need checks at run-time that
elements are appropriate for their usage), but makes a lot of things
more difficult. As an example, there are plenty of simple loops in
AdaControl that would need to be changed to recursive calls of special
functions (one for each loop).

2) Missing features. A casual look-up showed a number of queries that I
could not find. I reported to AdaCore, the response was: "yes, that's a
good idea, we'll add that later".

3) Unfriendly interface. It's not only lack of documentation, the "P_"
and "F_" convention makes everything harder to read, and is of no
benefit to the user. Moreover, it is a matter of implementation that
surfaces to the specification - very bad. Where ASIS follows strictly
the terms and structure of the ARM, LibAdalang uses abbreviated names
that do not even correspond the usual Ada vocabulary. And this cannot be
fixed without a major, incompatible, rework.

--
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52
https://www.adalog.fr

> We are talking about FSF-GNAT here. AFAIK, asis-gcc has not been pushed
> to FSF-GNAT.

What you call "asis-gcc" is a Pro version. We've never pushed any Pro version to FSF-GNAT, and there has never been any guarantee of correspondence between GNAT Pro and FSF-GNAT, so what you are demanding today for ASIS is unreasonable and unnecessary.

So assuming you are asking instead for some FSF version "close to asis-gcc", this version is available in the GCC 10.x branch, and similarly to asis-gcc which is on a long term, low changes branch at AdaCore, GCC 10.x is in the same state today. If you want an executable called "asis-gcc" then make a symbolic link from gcc (10.x) to asis-gcc and you have it.

> But this means that users of ASIS will be stuck to GCC 10.x, or will
> have to handle two versions of gcc at the same time, which is an endless
> source of burden.

The same is true for Pro users, no difference here: Pro users need to use GNAT x to compile, and ASIS-GCC y to generate trees. So what you are complaining about isn't different between Pro and community users, and making asis-gcc Pro available won't change that.

So to recap: you are asking for a Community version of "asis-gcc Pro": this version is available, it's GCC 10.x (10.3 being the latest available to date). And yes, it's a different version to generate trees than to compile Ada: the same is true for Pro users and they do not have specific issues with that.

Arno

Le 30/09/2021 à 09:29, Arnaud Charlet a écrit :
> So to recap: you are asking for a Community version of "asis-gcc
> Pro": this version is available, it's GCC 10.x (10.3 being the latest
> available to date). And yes, it's a different version to generate
> trees than to compile Ada: the same is true for Pro users and they do
> not have specific issues with that.
>
But it's not available from AdaCore's community page. For most users,
downloading and building from an FSF site is way too complicated. Call
it asis-gcc or not, what is needed is a simple way to install ASIS support.

(Making a tree generator separate from the compiler is for me another
error, although I can live with it. One of the main benefits of ASIS is
that the ASIS program has the same view of the code as the compiler -
but that's a separate issue).

--
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52
https://www.adalog.fr

On 30/09/2021 07:23, J-P. Rosen wrote:
> Le 30/09/2021 à 01:29, Luke A. Guest a écrit :
>>
>> On 29/09/2021 20:04, Emmanuel Briot wrote:
>>
>>> I suggested in an early message that perhaps the community could
>>> build an ASIS API on top of libadalang, if there is a need for that.
>>> I also suggested that libadalang documentation should be improved, I
>>> definitely agree with that one !
>>>
>>
>> Freely available iso asis spec would help here.
> Actually, it is. Apart from ISO verbiage, all the interesting parts of
> the ASIS standard is put as comments in the corresponding ASIS packages.
>
> Moreover, AdaCore kept this good habit for all the newly introduced
> features that support up to Ada 2012, which would make retrofitting them
> into an updated ASIS standard quite easy.
>

Are they gpl'd?

On 30/09/2021 07:23, J-P. Rosen wrote:

>> Freely available iso asis spec would help here.
> Actually, it is. Apart from ISO verbiage, all the interesting parts of
> the ASIS standard is put as comments in the corresponding ASIS packages.
>
> Moreover, AdaCore kept this good habit for all the newly introduced
> features that support up to Ada 2012, which would make retrofitting them
> into an updated ASIS standard quite easy.
>

Are they GPL'd and where are they?

Le 30/09/2021 à 09:53, Luke A. Guest a écrit :
> On 30/09/2021 07:23, J-P. Rosen wrote:
>> Le 30/09/2021 à 01:29, Luke A. Guest a écrit :
>>>
>>> On 29/09/2021 20:04, Emmanuel Briot wrote:
>>>
>>>> I suggested in an early message that perhaps the community could
>>>> build an ASIS API on top of libadalang, if there is a need for that.
>>>> I also suggested that libadalang documentation should be improved, I
>>>> definitely agree with that one !
>>>>
>>>
>>> Freely available iso asis spec would help here.
>> Actually, it is. Apart from ISO verbiage, all the interesting parts of
>> the ASIS standard is put as comments in the corresponding ASIS packages.
>>
>> Moreover, AdaCore kept this good habit for all the newly introduced
>> features that support up to Ada 2012, which would make retrofitting
>> them into an updated ASIS standard quite easy.
>>
>
> Are they gpl'd?
Yes. Here is a copy of the copyright notice of every ASIS module:

-- This specification is adapted from the Ada Semantic Interface --
-- Specification Standard (ISO/IEC 15291) for use with GNAT. In accordance --
-- with the copyright of that document, you can freely copy and modify this --
-- specification, provided that if you redistribute a modified version, any --
-- changes that you have made are clearly indicated. --
-- --
-- This specification also contains suggestions and discussion items --
-- related to revising the ASIS Standard according to the changes proposed --
-- for the new revision of the Ada standard. The copyright notice above, --
-- and the license provisions that follow apply solely to these suggestions --
-- and discussion items that are separated by the corresponding comment --
-- sentinels --
-- --
-- ASIS-for-GNAT is free software; you can redistribute it and/or modify it --
-- under terms of the GNU General Public License as published by the Free --
-- Software Foundation; either version 2, or (at your option) any later --
-- version. ASIS-for-GNAT is distributed in the hope that it will be use- --
-- ful, but WITHOUT ANY WARRANTY; without even the implied warranty of MER- --
-- CHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General --
-- Public License for more details. You should have received a copy of the --
-- GNU General Public License distributed with ASIS-for-GNAT; see file --
-- COPYING. If not, write to the Free Software Foundation, 51 Franklin --
-- Street, Fifth Floor, Boston, MA 02110-1301, USA. --

--
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52
https://www.adalog.fr