Prev: InformationWeek Gives Ada Black Eye
Next: Error when running gcc from GPS
From: Warren on 21 Apr 2010 15:54
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
From: Charmed Snark on 21 Apr 2010 16:31
Warren expounded in news:Xns9D61A1C47BBBWarrensBlatherings(a)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
From: Ludovic Brenta on 23 Apr 2010 20:11
Warren <ve3wwg(a)gmail.com> writes:

> Vadim Godunko expounded in news:d50d540f-8fdf-40ae-9301-
> 4958c6bdff4f(a)q15g2000yqj.googlegroups.com:
>
>> On Apr 21, 11:54pm, Warren <ve3...(a)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.
From: Stephen Leake on 24 Apr 2010 07:18
Warren <ve3wwg(a)gmail.com> writes:

> Vadim Godunko expounded in news:5867de55-7ca2-4c64-a72f-d2343153eef0
> @k36g2000yqn.googlegroups.com:
>
>> On Apr 23, 5:44 pm, Warren <ve3...(a)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
From: Vadim Godunko on 24 Apr 2010 08:54
On Apr 24, 12:18 am, Warren <ve3...(a)gmail.com> wrote:
> Vadim Godunko expounded in news:d50d540f-8fdf-40ae-9301-
> 4958c6bdf...(a)q15g2000yqj.googlegroups.com:
>
> > On Apr 21, 11:54 pm, Warren <ve3...(a)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.
 |  Next  |  Last
Pages: 1 2 3
Prev: InformationWeek Gives Ada Black Eye
Next: Error when running gcc from GPS