Autoconf & gnat Help Needed

Autoconf & gnat Help Needed

[Warren]

Has anyone here had experience using GNAT with autoconf/automake?

I'm attempting to port my autoconf from the original bdbbasic
project to the Ada rewrite project (z9basic). But I am having 
much difficulty getting autoconf, automake and libtool to
work together for a gnat build.     

In a nutshell, I have some static library modules built from:

lib_LTLIBRARIES = libz9.la
libz9_la_LDFLAGS = -static -version-info 1:0:1
libz9_la_SOURCES = misc.c terminal.c grammar.c parse.c cores.c ccmain.cc

This works OK, and produces libz9.a as expected.


But the problem is, I need to coax Automake to do the following
using libtool. The following is from a non-automake Makefile 
(which works ok):

DEBUG  = -g -O0
AFLAGS = $(DEBUG) -gnat05 -Wall -gnatwl -gnata -gnatVa -gnatf -gnatwr
CFLAGS = $(DEBUG) -I.. 
CXFLAGS = $(DEBUG) -I..

z9:  libz9.a z9-tokens.ads
     gnatmake $(AFLAGS) z9.adb
     gnatbind -n z9.ali
     gnatlink z9.ali --GCC=g++ --LINK=g++ -L. -lz9 -lncurses -lpanel


I need to accomplish the same in an automake fashion. I tried 
(unsuccessfully) the following:

z9$(EXE): libz9.a z9-tokens.ads  
        gnatmake $(AFLAGS) z9.adb
        gnatbind -n z9.ali
        gnatlink z9.ali ccmain.o --GCC=g++ --LINK=g++ -L. -lz9 -lncurses 
-lpanel

But the automake genned Makefile just ignored the gnat* steps and
attempted to link without the Ada modules.


Autoconf supports macros AC_PROG_CC and AC_PROG_CXX, but I don't 
see any support for gnat in aclocal.m4.

Surely someone else has bumped into this?

Warren

Re: Autoconf & gnat Help Needed

[Charmed Snark]

Warren expounded in news:Xns9D61A1C47BBBWarrensBlatherings@188.40.43.245:

> Has anyone here had experience using GNAT with autoconf/automake?
..
> I need to accomplish the same in an automake fashion. I tried 
> (unsuccessfully) the following:
> 
> z9$(EXE): libz9.a z9-tokens.ads  
>         gnatmake $(AFLAGS) z9.adb
>         gnatbind -n z9.ali
>         gnatlink z9.ali ccmain.o --GCC=g++ --LINK=g++ -L. -lz9 ...

Ok, I nearly got it now:

z9$(EXEEXT): libz9.la z9-tokens.ads
        gnatmake $(AFLAGS) z9.adb
        gnatbind -n z9.ali
        gnatlink z9.ali --GCC=g++ --LINK=g++ -L. -lz9 ...

This doesn't see libz9.a, because libtool puts it in
./.libs/libz9.a.  I could cheat and refer to that, but
I'd prefer to coax libtool into doing the "Right Thing".

So I just gotta figure how to get libtool to link this
with gnatlink, replacing the "gnatlink" step above.

Warren

Re: Autoconf & gnat Help Needed

[Georg Bauhaus]

On 21.04.10 21:54, Warren wrote:
> Has anyone here had experience using GNAT with autoconf/automake?

I think, no, I know I am not the only one having used
GNU make in preference to the very thing that purports
to solve the problem, that, actually, it is creating.

automess.

Re: Autoconf & gnat Help Needed

[Warren]

Georg Bauhaus expounded in news:4bd023a8$0$6881$9b4e6d93@newsspool2.arcor-
online.net:

> On 21.04.10 21:54, Warren wrote:
>> Has anyone here had experience using GNAT with autoconf/automake?
> 
> I think, no, I know I am not the only one having used
> GNU make in preference to the very thing that purports
> to solve the problem, that, actually, it is creating.
> 
> automess.

Not much disagreement there, and I'm even less fond of
libtool. But it's going to be necessary for me to use
this for portability to all the platforms that I intend
to support.

Warren

Re: Autoconf & gnat Help Needed

[Stephen Leake]

Warren <ve3wwg@gmail.com> writes:

> Has anyone here had experience using GNAT with autoconf/automake?

My advice is to stop using the autotools, and use gprbuild instead.

gprbuild knows how to build C libraries and link them with Ada. It can
also use a C main, if necessary.

-- 
-- Stephe

Re: Autoconf & gnat Help Needed

[Warren]

Stephen Leake expounded in news:82sk6nn4vn.fsf@stephe-leake.org:

> Warren <ve3wwg@gmail.com> writes:
> 
>> Has anyone here had experience using GNAT with autoconf/automake?
> 
> My advice is to stop using the autotools, and use gprbuild instead.
> 
> gprbuild knows how to build C libraries and link them with Ada. It can
> also use a C main, if necessary.

Unfortunately, there is more to this than just the build. 
I am mostly concerned about the ./configure and the generated
config.h file.  Autoconf is critical for wide platform support.

But you gave me an idea.  Maybe I can just use autoconf and do away 
with automake and libtool.  I still need to use the libtool's 
library libtdl (I think it was), but that shouldn't be a problem.
That way I can still use make (gmake), as I have always done.

Warren

Re: Autoconf & gnat Help Needed

[Warren]

Warren expounded in news:Xns9D6274A3FCC0CWarrensBlatherings@
188.40.43.245:

> Stephen Leake expounded in news:82sk6nn4vn.fsf@stephe-leake.org:
> 
>> Warren <ve3wwg@gmail.com> writes:
>> 
>>> Has anyone here had experience using GNAT with autoconf/automake?
...

Ok, I got this thang working together now, including
autoconf, automake and libtool. For anyone interested,
this is one way you can do it.

My executable is named z9. So in Makefile.am specify:

bin_PROGRAMS = z9

as per usual. I also build a static library containing 
all the related C/C++ modules (mine included a C++ main
program, thanks to ncurses).  So for the final target
specify something like:

z9$(EXEEXT): libz9.la 
   gnatmake $(AFLAGS) z9.adb
   gnatbind -n z9.ali
   libtool --mode=link --tag=CC gnatlink z9.ali --GCC=g++ \
       --LINK=g++ -L. -lz9 -lncurses -lpanel -o z9

The $(EXEEXT) is necessary for Cygwin builds.

File libz9.la is the surrogate for the static library of
C/C++ programs, which is listed as a dependency to
cause it to be created by libtool first. The
AFLAGS is just GNAT compile options, of the form:

DEBUG  = -g -O0
AFLAGS = $(DEBUG) -gnat05 -Wall -gnatwl ...

z9.adb was the starting point for my Ada code. It gets
invoked by the C++ main program. Specifying that, causes
all dependant Ada units to be compiled as usual by
gnatmake.

The libtool --mode=link is the tricky part:

You have to lie to libtool with --tag=CC (for C++) for 
a C++ build. 

I didn't try it, but presumably if you only have C 
modules, --tag=C will work (also remove "--GCC=g++" 
and "--LINK=g++" as well from the libtool command).

Then specify the entire rest of the gnatlink command line. 
libtool does however require that you explicitly specify 
the output file with the -o option ("-o z9", in this case).

Life is good, albeit a bit complex.

Warren

Re: Autoconf & gnat Help Needed

[Stephen Leake]

Warren <ve3wwg@gmail.com> writes:

> Stephen Leake expounded in news:82sk6nn4vn.fsf@stephe-leake.org:
>
>> Warren <ve3wwg@gmail.com> writes:
>> 
>>> Has anyone here had experience using GNAT with autoconf/automake?
>> 
>> My advice is to stop using the autotools, and use gprbuild instead.
>> 
>> gprbuild knows how to build C libraries and link them with Ada. It can
>> also use a C main, if necessary.
>
> Unfortunately, there is more to this than just the build. 
> I am mostly concerned about the ./configure and the generated
> config.h file.  Autoconf is critical for wide platform support.

Apparently you have source code in C as well as Ada? My sympathies :).

> But you gave me an idea.  Maybe I can just use autoconf and do away 
> with automake and libtool.  

Yes.

> I still need to use the libtool's library libtdl (I think it was), but
> that shouldn't be a problem. 

I'm not familiar with that tool; what does it do?

> That way I can still use make (gmake), as I have always done.

I always run gprbuild from Gnu make.

-- 
-- Stephe

Re: Autoconf & gnat Help Needed

[Warren]

Stephen Leake expounded in news:82ochamzq1.fsf@stephe-leake.org:

> Warren <ve3wwg@gmail.com> writes:
>> Stephen Leake expounded in news:82sk6nn4vn.fsf@stephe-leake.org:
>>> Warren <ve3wwg@gmail.com> writes:
>>> 
>>>> Has anyone here had experience using GNAT with autoconf/automake?
>>> 
>>> My advice is to stop using the autotools, and use gprbuild instead.
>>> 
>>> gprbuild knows how to build C libraries and link them with Ada. It 
can
>>> also use a C main, if necessary.
>>
>> Unfortunately, there is more to this than just the build. 
>> I am mostly concerned about the ./configure and the generated
>> config.h file.  Autoconf is critical for wide platform support.
> 
> Apparently you have source code in C as well as Ada? My sympathies :).

For a basic interpreter, making use of ncurses, libgmp, libgsl, 
and PostgreSQL etc., it is unavoidable. :)  I tried to avoid C++
like the plague, but ncurses requires a C++ main, if GNAT exceptions
are to work correctly. I'm not sure of the details why, but a GNAT
exception + ncurses and a C or gnat main leads to an abort. 
Switching to a C++ main program has corrected that.

>> I still need to use the libtool's library libtdl (I think it was), but
>> that shouldn't be a problem. 
> 
> I'm not familiar with that tool; what does it do?

It's main claim to fame is to provide a uniform way of dealing
with shared libraries and dlls on a given platform. I mainly 
need the libtool's library for working with dynamic library 
loading in a platform neutral way, which it does very well.
I may need to create shared library components down the
road, but that is on hold for now.

>> That way I can still use make (gmake), as I have always done.
> 
> I always run gprbuild from Gnu make.

As you can see from my other post yesterday, I did manage to
get things working. I posted the relevant details.

Warren

Re: Autoconf & gnat Help Needed

[Vadim Godunko]

On Apr 23, 5:44 pm, Warren <ve3...@gmail.com> wrote:
>
> For a basic interpreter, making use of ncurses, libgmp, libgsl,
> and PostgreSQL etc., it is unavoidable. :)  I tried to avoid C++
> like the plague, but ncurses requires a C++ main, if GNAT exceptions
> are to work correctly. I'm not sure of the details why, but a GNAT
> exception + ncurses and a C or gnat main leads to an abort.
> Switching to a C++ main program has corrected that.
>
Did you try to pass -shared to gnatbind?

Re: Autoconf & gnat Help Needed

[Warren]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 919 bytes --]

Vadim Godunko expounded in news:5867de55-7ca2-4c64-a72f-d2343153eef0
@k36g2000yqn.googlegroups.com:

> On Apr 23, 5:44�pm, Warren <ve3...@gmail.com> wrote:
>>
>> For a basic interpreter, making use of ncurses, libgmp, libgsl,
>> and PostgreSQL etc., it is unavoidable. :) �I tried to avoid C++
>> like the plague, but ncurses requires a C++ main, if GNAT exceptions
>> are to work correctly. I'm not sure of the details why, but a GNAT
>> exception + ncurses and a C or gnat main leads to an abort.
>> Switching to a C++ main program has corrected that.
>>
> Did you try to pass -shared to gnatbind?

No, but is that really relevant? 

The problem was not library linkage, but the fact that 
if an exception was raised in the Ada modules, the 
exception handler would not work -- the whole unit 
would abort.

In fact I was able to interact with ncurses and everything
else C wise, until I did a "raise".

Warren

Re: Autoconf & gnat Help Needed

[Stephen Leake]

Warren <ve3wwg@gmail.com> writes:

> Vadim Godunko expounded in news:5867de55-7ca2-4c64-a72f-d2343153eef0
> @k36g2000yqn.googlegroups.com:
>
>> On Apr 23, 5:44 pm, Warren <ve3...@gmail.com> wrote:
>>>
>>> For a basic interpreter, making use of ncurses, libgmp, libgsl,
>>> and PostgreSQL etc., it is unavoidable. :)  I tried to avoid C++
>>> like the plague, but ncurses requires a C++ main, if GNAT exceptions
>>> are to work correctly. I'm not sure of the details why, but a GNAT
>>> exception + ncurses and a C or gnat main leads to an abort.
>>> Switching to a C++ main program has corrected that.
>>>
>> Did you try to pass -shared to gnatbind?
>
> No, but is that really relevant? 
>
> The problem was not library linkage, but the fact that 
> if an exception was raised in the Ada modules, the 
> exception handler would not work -- the whole unit 
> would abort.

Lots of things are relevant in exception handling.

First is the exception handling mechanism; set-jump/long-jump vs zero
cost. GNAT supports both, with zero cost the default; Windows dlls
require sj/lj.

It may be that using a C++ main also implies the sj/lj mechanism.

-- 
-- Stephe

Re: Autoconf & gnat Help Needed

[Warren]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1308 bytes --]

Stephen Leake expounded in news:82fx2lm74h.fsf@stephe-leake.org:

> Warren <ve3wwg@gmail.com> writes:
> 
>> Vadim Godunko expounded in news:5867de55-7ca2-4c64-a72f-d2343153eef0
>> @k36g2000yqn.googlegroups.com:
>>
>>> On Apr 23, 5:44 pm, Warren <ve3...@gmail.com> wrote:
>>>>
>>>> For a basic interpreter, making use of ncurses, libgmp, libgsl,
>>>> and PostgreSQL etc., it is unavoidable. :)  I tried to avoid C++
>>>> like the plague, but ncurses requires a C++ main, if GNAT exceptions
>>>> are to work correctly. I'm not sure of the details why, but a GNAT
>>>> exception + ncurses and a C or gnat main leads to an abort.
>>>> Switching to a C++ main program has corrected that.
>>>>
>>> Did you try to pass -shared to gnatbind?
>>
>> No, but is that really relevant? 
>>
>> The problem was not library linkage, but the fact that 
>> if an exception was raised in the Ada modules, the 
>> exception handler would not work -- the whole unit 
>> would abort.
> 
> Lots of things are relevant in exception handling.
> 
> First is the exception handling mechanism; set-jump/long-jump vs zero
> cost. GNAT supports both, with zero cost the default; Windows dlls
> require sj/lj.
> 
> It may be that using a C++ main also implies the sj/lj mechanism.

Ok, but how is that connected with "-shared"?

Warren

Re: Autoconf & gnat Help Needed

[Alex R. Mosteo]

Warren wrote:

> Stephen Leake expounded in news:82fx2lm74h.fsf@stephe-leake.org:
> 
>> Warren <ve3wwg@gmail.com> writes:
>> 
>>> Vadim Godunko expounded in news:5867de55-7ca2-4c64-a72f-d2343153eef0
>>> @k36g2000yqn.googlegroups.com:
>>>
>>>> On Apr 23, 5:44 pm, Warren <ve3...@gmail.com> wrote:
>>>>>
>>>>> For a basic interpreter, making use of ncurses, libgmp, libgsl,
>>>>> and PostgreSQL etc., it is unavoidable. :)  I tried to avoid C++
>>>>> like the plague, but ncurses requires a C++ main, if GNAT exceptions
>>>>> are to work correctly. I'm not sure of the details why, but a GNAT
>>>>> exception + ncurses and a C or gnat main leads to an abort.
>>>>> Switching to a C++ main program has corrected that.
>>>>>
>>>> Did you try to pass -shared to gnatbind?
>>>
>>> No, but is that really relevant?
>>>
>>> The problem was not library linkage, but the fact that
>>> if an exception was raised in the Ada modules, the
>>> exception handler would not work -- the whole unit
>>> would abort.
>> 
>> Lots of things are relevant in exception handling.
>> 
>> First is the exception handling mechanism; set-jump/long-jump vs zero
>> cost. GNAT supports both, with zero cost the default; Windows dlls
>> require sj/lj.
>> 
>> It may be that using a C++ main also implies the sj/lj mechanism.
> 
> Ok, but how is that connected with "-shared"?

Stab in the dark here; I've read in the past when looking for fully 
statically linked programs that shared runtimes are/were needed for c++ 
exception mechanisms to work; or at least to keep all corner cases covered.

So I wouldn't be surprised if -shared did indeed affect some exception 
related stuff.

What I read was something similar to this, but it was a long time ago:

http://www.trilithium.com/johan/2005/06/static-libstdc/

Re: Autoconf & gnat Help Needed

[Warren]

Alex R. Mosteo expounded in
news:hr61ms$fsh$2@news.eternal-september.org: 

> Warren wrote:
> 
>> Stephen Leake expounded in news:82fx2lm74h.fsf@stephe-leake.org:
>> 
>>> Warren <ve3wwg@gmail.com> writes:
>>> 
>>>> Vadim Godunko expounded in
>>>> news:5867de55-7ca2-4c64-a72f-d2343153eef0 
>>>> @k36g2000yqn.googlegroups.com: 
>>>>
>>>>> On Apr 23, 5:44 pm, Warren <ve3...@gmail.com> wrote:
>>>>>>
>>>>>> For a basic interpreter, making use of ncurses, libgmp, libgsl,
>>>>>> and PostgreSQL etc., it is unavoidable. :)  I tried to avoid C++
>>>>>> like the plague, but ncurses requires a C++ main, if GNAT
>>>>>> exceptions are to work correctly. I'm not sure of the details
>>>>>> why, but a GNAT exception + ncurses and a C or gnat main leads to
>>>>>> an abort. Switching to a C++ main program has corrected that.
>>>>>>
>>>>> Did you try to pass -shared to gnatbind?
>>>>
>>>> No, but is that really relevant?
>>>>
>>>> The problem was not library linkage, but the fact that
>>>> if an exception was raised in the Ada modules, the
>>>> exception handler would not work -- the whole unit
>>>> would abort.
>>> 
>>> Lots of things are relevant in exception handling.
>>> 
>>> First is the exception handling mechanism; set-jump/long-jump vs
>>> zero cost. GNAT supports both, with zero cost the default; Windows
>>> dlls require sj/lj.
>>> 
>>> It may be that using a C++ main also implies the sj/lj mechanism.
>> 
>> Ok, but how is that connected with "-shared"?
> 
> Stab in the dark here; I've read in the past when looking for fully 
> statically linked programs that shared runtimes are/were needed for
> c++ exception mechanisms to work; or at least to keep all corner cases
> covered. 
> 
> So I wouldn't be surprised if -shared did indeed affect some exception
> related stuff.
> 
> What I read was something similar to this, but it was a long time ago:
> 
> http://www.trilithium.com/johan/2005/06/static-libstdc/

I'll have to read that more closely when I have some time,
but you've convinced me. I'd really like to eliminate any
C++ dependence, since that continues to change with the 
wind.

Thanks, Warren

Re: Autoconf & gnat Help Needed

[Vadim Godunko]

On Apr 21, 11:54 pm, Warren <ve3...@gmail.com> wrote:
> Has anyone here had experience using GNAT with autoconf/automake?
>
I used them long time ago. I don't known any project which still use
them now, but them was used in old versions of PolyORB and QtAda.

Re: Autoconf & gnat Help Needed

[Warren]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 793 bytes --]

Vadim Godunko expounded in news:d50d540f-8fdf-40ae-9301-
4958c6bdff4f@q15g2000yqj.googlegroups.com:

> On Apr 21, 11:54�pm, Warren <ve3...@gmail.com> wrote:
>> Has anyone here had experience using GNAT with autoconf/automake?
>>
> I used them long time ago. I don't known any project which still use
> them now, but them was used in old versions of PolyORB and QtAda.

I just feel that if an Ada (gnat) based project is going
to gain any package-level respect from the maintainers
of Debian/etc., it will need to be autoconf ready.

This becomes especially crucial when you try to make the
project build under HPUX, Solaris, AIX and OSX in addition
to usual Linux/*BSD lineup. The environments are different 
enough to frustrate any simple minded configuration 
management system.

Warren

Re: Autoconf & gnat Help Needed

[Ludovic Brenta]

Warren <ve3wwg@gmail.com> writes:

> Vadim Godunko expounded in news:d50d540f-8fdf-40ae-9301-
> 4958c6bdff4f@q15g2000yqj.googlegroups.com:
>
>> On Apr 21, 11:54pm, Warren <ve3...@gmail.com> wrote:
>>> Has anyone here had experience using GNAT with autoconf/automake?
>>>
>> I used them long time ago. I don't known any project which still use
>> them now, but them was used in old versions of PolyORB and QtAda.
>
> I just feel that if an Ada (gnat) based project is going
> to gain any package-level respect from the maintainers
> of Debian/etc., it will need to be autoconf ready.

On the contrary; in most of my Debian packages, I bypass the brittle
autocrap, evil recursive makefiles (that do not play well with the
parallel build support in gnatmake) and unmaintainable libtool mess in
favour of a single, simple, hand-written makefile and one GNAT project
file.  This works MUCH better in my experience.

I can do that because I do not care about portability to platforms other
than Debian and because I can control precisely the build-dependencies.
But I do care about portability of Debian across hardware architectures
and kernels; I don't need autocrap for this because Ada is very
portable.

> This becomes especially crucial when you try to make the project build
> under HPUX, Solaris, AIX and OSX in addition to usual Linux/*BSD
> lineup. The environments are different enough to frustrate any simple
> minded configuration management system.

That's correct but assumes you want to take the burden of doing all this
by yourself.

-- 
Ludovic Brenta.

Re: Autoconf & gnat Help Needed

[Charmed Snark]

Ludovic Brenta expounded in news:871ve53e1h.fsf@ludovic-brenta.org:

> Warren <ve3wwg@gmail.com> writes:
>> Vadim Godunko expounded in news:d50d540f-8fdf-40ae-9301-
>> 4958c6bdff4f@q15g2000yqj.googlegroups.com:
>>> On Apr 21, 11:54pm, Warren <ve3...@gmail.com> wrote:
>>>> Has anyone here had experience using GNAT with autoconf/automake?
..
> On the contrary; in most of my Debian packages, I bypass the brittle
> autocrap, evil recursive makefiles (that do not play well with the
..
> I can do that because I do not care about portability to platforms 
other
> than Debian 

But one platform vastly simplifies things ;-)

>> This becomes especially crucial when you try to make the project build
>> under HPUX, Solaris, AIX and OSX in addition to usual Linux/*BSD
>> lineup. The environments are different enough to frustrate any simple
>> minded configuration management system.
> 
> That's correct but assumes you want to take the burden of doing all 
this
> by yourself.

But that is precisely what the autocrap is for.  It does work, 
albeit a bit unweildy.  I resisted it myself for years, but once 
you embrace the darkside, you do find that it can work, when 
sufficiently coaxed.

Warren

Re: Autoconf & gnat Help Needed

[Robert A Duff]

Ludovic Brenta <ludovic@ludovic-brenta.org> writes:

> Warren <ve3wwg@gmail.com> writes:
>
>> Vadim Godunko expounded in news:d50d540f-8fdf-40ae-9301-
>> 4958c6bdff4f@q15g2000yqj.googlegroups.com:
>>
>>> On Apr 21, 11:54pm, Warren <ve3...@gmail.com> wrote:
>>>> Has anyone here had experience using GNAT with autoconf/automake?

I have.  It's a nightmare, as others have said.

If you absolutely must use these tools, I suggest you
minimize their use.  Most of what you need can be
done using gprbuild, which can be called from
a make file (preferably hand written, not generated
via 37 levels of confusing tools).

> >> I used them long time ago. I don't known any project which still use
> >> them now, but them was used in old versions of PolyORB and QtAda.

PolyORB still uses autoconf, but I got rid of automake, which
was a big improvement.

> On the contrary; in most of my Debian packages, I bypass the brittle
> autocrap, evil recursive makefiles...

Here's a paper, "Recursive Make Considered Harmful":

http://miller.emu.id.au/pmiller/books/rmch/

which explains why recursive makefiles are evil,
and how to do it right.  (Of course, most of what
make does is done better by gprbuild -- but not
everything.)

>... (that do not play well with the
> parallel build support in gnatmake)...

Not just that.  Recursive make files don't even work well
with make -- they are grossly inefficient.  Even more so
under cygwin.

>...and unmaintainable libtool mess in
> favour of a single, simple, hand-written makefile and one GNAT project
> file.  This works MUCH better in my experience.

- Bob

Re: Autoconf & gnat Help Needed

[Vadim Godunko]

On Apr 24, 12:18 am, Warren <ve3...@gmail.com> wrote:
> Vadim Godunko expounded in news:d50d540f-8fdf-40ae-9301-
> 4958c6bdf...@q15g2000yqj.googlegroups.com:
>
> > On Apr 21, 11:54 pm, Warren <ve3...@gmail.com> wrote:
> >> Has anyone here had experience using GNAT with autoconf/automake?
>
> > I used them long time ago. I don't known any project which still use
> > them now, but them was used in old versions of PolyORB and QtAda.
>
> I just feel that if an Ada (gnat) based project is going
> to gain any package-level respect from the maintainers
> of Debian/etc., it will need to be autoconf ready.
>
By the way, configure equivalent, written in Ada, included in
Matreshka, it is still relatively simple, but good enough to detect
several important properties of target system like size of the
address, endianess, support of atomic operations by architecture and
support for MMX/SSE by Ada compiler.

Re: Autoconf & gnat Help Needed

[Warren]

Vadim Godunko expounded in news:ddd15bde-3294-416e-916c-
64c6c686b31f@b33g2000yqc.googlegroups.com:

> By the way, configure equivalent, written in Ada, included in
> Matreshka, it is still relatively simple, but good enough to detect
> several important properties of target system like size of the
> address, endianess, support of atomic operations by architecture and
> support for MMX/SSE by Ada compiler.

But I need more than that. There are platform issues with NaN, infinity
constants and their handling. Also many differences in curses. 

Solaris adds grief for C types of attributes and the lack of/difference 
in certain attribute functions. I also need to know whether you can 
customize the colour palette in a given implementation of curses (and 
pdcurses). Include files vary by platform for some of the C routines, 
which will be called by the Ada code. Whether or not I have alloca() 
support is another important configuration item.

Add to that release to release changes in 3rd party support like libgsl,
libgmp and PostgreSQL and you'll find a strong need for extensive 
configuration control. So autocrap does control all that for me, along 
with a few hand-crafted platform tests where it falls short.

Warren