Creating and using Ada packages: need refinement

Creating and using Ada packages: need refinement

[Ivan Levashew]

Hello!

My question is: how to create flexible Ada packages and what should they 
look like? Enlist the make variables, for example. I'm not happy with 
what I currently see. Ada packages are not easy to finetune.

Let's suppose that our project is rather complex. It contains both Ada 
and C code and may be C++.

Let's start with the following list:
ADA=                          gnatgcc, gcc
Name of the compiler used to compile Ada. Different compilers can be 
used to compile Ada, C and C++. In particular, different instances of 
GCC. On the most OSes it's $(which gcc), but on FreeBSD and Mac OS X 
it's better to use another compiler for C and C++. On FreeBSD Ada 
compiler is based on GCC 3.x, and on Mac OS X Apple GCC is supposed to 
be used instead of FSF one. So the ./configure script should first look 
for gnatgcc.
ADAFLAGS=                     -I. -O2
Flags used when invoking $(ADA)
CC=                           gcc
C compiler invokation command
CXX=                          g++
C++ compiler invokation command
CFLAGS=                       -g -O2
C-specific flags (not applicable to C++)
CXXFLAGS=                     -g -O2
C++-specific flags
CPP=                          gcc -E
C preprocessor invokation command
CXXCPP=                       g++ -E
INCLUDES, DEFS, LIBS
Additional flags.

The rightest way to call C compiler so far:
$(CC) $(DEFS) $(INCLUDES) $(CPPFLAGS) $(CFLAGS)

I also saw: $(AM_CPPFLAGS) $(AM_CFLAGS) $(DEFAULT_INCLUDES)

The rightest way to invoke Ada compiler (?? not sure)
$(ADA) $(ADAFLAGS) -c
Adaproject-created project's Makefile contained ${ADA} ${ADAFLAGS}. ${} 
instead of $(). Does it make any sense?

Next.
GNATBIND, GNATLINK, GNATMAKE
usually correspond to gnatbind, gnatlink and gnatmake
GNATMAKEBINDFLAGS, GNATMAKELDFLAGS -- I saw them in GtkAda. I think it's 
a bad idea. For example, GNATMAKELDFLAGS = -largs -L. -lgtkada 
$(GTK_LIBS) in the GtkAda's Makefile. I don't like it because it is 
supposed to be used with $(GNATMAKE). And what if one morning one would 
like to call $(GNATLINK) explicitly? So I suppose it would be better to 
define GNATBINDFLAGS, GNATLDFLAGS (or better name it GNATLINKFLAGS?) and 
GNATMAKEFLAGS.
So far, gnatmake invokation is:
$(GNATMAKE) -cargs $(ADAFLAGS) -bargs $(GNATBINDFLAGS) \
   -largs $(GNATLDFLAGS) -margs $(GNATMAKEFLAGS)

I also saw $(GNATFLAGS). Is it supposed to be passed to every gnat* 
command? Or does it serve the same purpose as ADAFLAGS, just another 
name? It looks like there was no strict convention in Ada packages. No 
any single de facto standard. Developers on OSes where compilation is 
easy didn't care much about flexibility of their packages. And I'm now 
gathering obstacle by obstacle because of this inflexibility.
Consider this example:
GtkAda-2.8.1/testgtk/Makefile:
GNATFLAGS = @CFLAGS@ -gnata -gnatws
Pass CFLAGS to gnat! Awful! Yeah, right, gnat knows that -arch ppc is a 
single argument, that ppc is not a project name or so.

I am to create crapload of shell scripts to make illusion that 
everything is OK. Illusion that GCC is the same for both Ada and C.
Instead of passing CFLAGS, etc. to ./configure I'd like to circumvent 
./configure-make mechanisms. CFLAGS and Co. are to be written to 
KRUNCH_* environment variables, and "gcc", "gnatmake" shell scripts are 
to pass all these flags to the actual compiler.

It is temporary solution, we can't accumulate krunches. So far, I'd like 
to see a guidelines in the "Ada programming" wikibook.

Another point:
I'd like to use Apple GCC as linker. Should I alter GNATMAKELDFLAGS with 
--LINK="" or ideal Ada packages must care about using the right compiler 
by itself? When gcc or g++ is used to link, they are referenced by 
$(CCLD) or $(CXXLD) respectivelly.

My point of view expresses my own only problems. I'd like my Ada 
packages to be convenient for use by everybody, so I encourage you to 
participate in creating a single de facto standard.

Re: Creating and using Ada packages: need refinement

[Georg Bauhaus]

On Sat, 2008-03-15 at 01:09 +0600, Ivan Levashew wrote:
> Hello!
> 
> My question is: how to create flexible Ada packages and what should they 
> look like?

You mean the source text? Package source text that needs
preprocessing to take this or that shape?

>  Enlist the make variables, for example. I'm not happy with 
> what I currently see. Ada packages are not easy to finetune.

Project files can evaluate environment variables.
See "external" in the project file documentation.

> Let's suppose that our project is rather complex. It contains both Ada 
> and C code and may be C++.
...
>  So the ./configure script should first look 
> for gnatgcc.

It might be a lot easier to configure configure to just
call gnatmake with the appropriate project file.

Re: Creating and using Ada packages: need refinement

[Ivan Levashew]

Georg Bauhaus пишет:
> On Sat, 2008-03-15 at 01:09 +0600, Ivan Levashew wrote:
>> Hello!
>>
>> My question is: how to create flexible Ada packages and what should they 
>> look like?
> 
> You mean the source text? Package source text that needs
> preprocessing to take this or that shape?
No, no any preprocessing. I mean configure&Makefile flags tunability.

Basically, all these ADAFLAGS are to be passed to just configure. It is 
up to configure to incorporate them into resulting Makefile.

> Project files can evaluate environment variables.
> See "external" in the project file documentation.

There can be no any project file.

Re: Creating and using Ada packages: need refinement

[Simon Wright]

Ivan Levashew <octagram@bluebottle.com> writes:

> Georg Bauhaus пишет:

>> Project files can evaluate environment variables.
>> See "external" in the project file documentation.
>
> There can be no any project file.

If you mean "I refuse to use project files" then you are creating a
world of pain for yourself -- no one will have GNAT without gnatmake &
gprmake.

Re: Creating and using Ada packages: need refinement

[Ivan Levashew]

Simon Wright пишет:
> "I refuse to use project files"
So in case I meet a non-project-based Ada package, must I convert it to 
a project-based one?

> no one will have GNAT without gnatmake &
> gprmake.

And how should one invoke gnatmake from Makefile?
My cmdline has grown to
$(GNATMAKE) --GNATBIND=$(GNATBIND) --GNATLINK=$(GNATLINK) \
   -cargs $(ADAFLAGS) -bargs $(GNATBINDFLAGS) \
   -largs $(GNATLDFLAGS) --LINK="$(CCLD) $(CCLDFLAGS)" \
   -margs $(GNATMAKEFLAGS) $(GNATFLAGS)

-- 
If you want to get to the top, you have to start at the bottom

Re: Creating and using Ada packages: need refinement

[Ludovic Brenta]

Ivan Levashew writes:
> Simon Wright пишет:
>> "I refuse to use project files"
> So in case I meet a non-project-based Ada package, must I convert it
> to a project-based one?

Yes, preferably.

>> no one will have GNAT without gnatmake &
>> gprmake.
>
> And how should one invoke gnatmake from Makefile?
> My cmdline has grown to
> $(GNATMAKE) --GNATBIND=$(GNATBIND) --GNATLINK=$(GNATLINK) \
>   -cargs $(ADAFLAGS) -bargs $(GNATBINDFLAGS) \
>   -largs $(GNATLDFLAGS) --LINK="$(CCLD) $(CCLDFLAGS)" \
>   -margs $(GNATMAKEFLAGS) $(GNATFLAGS)

That's ugly.  Look at how the Debian Policy for Ada solves the problem
of using multiple libraries in a single program:

http://www.ada-france.org/debian/debian-ada-policy.html

-- 
Ludovic Brenta.

Re: Creating and using Ada packages: need refinement

[Ivan Levashew]

Ludovic Brenta пишет:
> 
> http://www.ada-france.org/debian/debian-ada-policy.html
> 
It led me to
http://web.archive.org/web/20041213015958/http://cert.uni-stuttgart.de/files/ada/gnae/gnae-0.5.html

Yeah, that's kind of what I was looking for.

-- 
If you want to get to the top, you have to start at the bottom

Re: Creating and using Ada packages: need refinement

[Ivan Levashew]

Ludovic Brenta пишет:
> That's ugly.  Look at how the Debian Policy for Ada solves the problem
> of using multiple libraries in a single program:
> 
> http://www.ada-france.org/debian/debian-ada-policy.html
I can't make my packages just for Debian, however I can ease life of 
Debian maintainers. And GNAE documentation was removed from website. I'm 
not sure if I can rely on it. Adaproject seems to be unmaintained. I 
wasn't able to install it with just ./configure-make-make install. 
./config.status replaces @prefix@ with /usr/local which is OK, but 
@exec_prefix@ with ${prefix} which is not OK in the resulting shell 
script file. Adaproject's out-of-box licenses are just BSD & GPL. No any 
GMGPL. I might have better luck with raw Autotools.

I have found old similar topic:

http://groups.google.ru/group/comp.lang.ada/browse_frm/thread/ab5f27c42c253ac5/1500582f20e9b1b8?hl=ru&tvc=1

I had an impression that virtually nobody cares about Ada packages' 
usage on a non-standard platform like Mac OS X.

Consider this example:
http://developer.apple.com/technotes/tn2005/tn2137.html

 > env CFLAGS="-O -g -isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch \
 > i386 -arch ppc" LDFLAGS="-arch i386 -arch ppc"   ./configure \
 > --prefix=${HOME}/Hello --disable-dependency-tracking
That's how average GNU autotools-based packages are compiled on Mac OS 
X. Autotools' generated packages were flexible enough to make it 
possible to compile many of them without headaches. ./configure 
invocation is virtually the same for the most of Autotools packages. You 
can even make a proxy script that sets these CFLAGS&LDFLAGS&configure 
parameters to make its invokation shorter. My aim is to write such a 
line for an ideal Ada-containing package. I'd like to make my Ada 
packages OS-agnostic but easily tunable for my OS.

-- 
If you want to get to the top, you have to start at the bottom

Re: Creating and using Ada packages: need refinement

[Ludovic Brenta]

Ivan Levashew wrote:
> Ludovic Brenta пишет:
> > That's ugly.  Look at how the Debian Policy for Ada solves the problem
> > of using multiple libraries in a single program:
> >
> > http://www.ada-france.org/debian/debian-ada-policy.html
> I can't make my packages just for Debian, however I can ease life of
> Debian maintainers. And GNAE documentation was removed from website. I'm
> not sure if I can rely on it.

You can at least rely on the Debian policy for Ada. It is nice if you
make Debian maintainers' lives easier, provided there is a Debian
maintainer for your package :)

> Adaproject seems to be unmaintained.

What is adaproject?

> I wasn't able to install it with just ./configure-make-make install.

As you have probably guessed, I detest the autotools with a vengeance.
They are slow, brittle, cryptic, unmaintainable, subtly incompatible
with other versions of themselves, and they exist only to overcome the
deficiencies and lack of portability of C and C++. We use Ada. We
don't need no stupid autotools. In simple cases, one GNAT project file
is sufficient. Nowadays, with gprmake, they can even handle multi-
language projects, so even these are "simple cases". In complex cases,
a complementary Makefile can call gnatprep or pass variables to the
project file e.g. to adjust the contents of the Source_Dirs or package
Naming. It can also simply pass build options on the gnatmake or
gprmake command line if you need to override or complement the options
in package Compiler, Linker or Binder. And this is true on all
platforms, except perhaps the most exotic ones like the ones from
Redmond, which don't even have "make" by default.

> I had an impression that virtually nobody cares about Ada packages'
> usage on a non-standard platform like Mac OS X.

Mac OS X is much more standard than e.g. Microsoft Windows, and there
are people who care about it. They are on http://www.macada.org

--
Ludovic Brenta.

Re: Creating and using Ada packages: need refinement

[Ivan Levashew]

Ludovic Brenta О©╫О©╫О©╫О©╫О©╫:
>> Adaproject seems to be unmaintained.
> 
> What is adaproject?
http://sourceforge.net/projects/adaprojet/

> deficiencies and lack of portability of C and C++. We use Ada. We
> don't need no stupid autotools. In simple cases, one GNAT project file
> is sufficient. Nowadays, with gprmake, they can even handle multi-
> language projects, so even these are "simple cases".
BTW, is gprbuild publicly available?

http://libre.adacore.com/viewvc/trunk/gps/distrib/features?revision=122527&view=markup
 > NF-43-H216-003 gprbuild no longer packaged with GPS (2008-02-19)
It sounds like one might discover older gprbuild version in some gps 
revision if search carefully. I didn't find it yet.

> Mac OS X is much more standard than e.g. Microsoft Windows, and there
> are people who care about it. They are on http://www.macada.org
I didn't noticed they are using Ada in an advanced way.
Provided that:

http://news.gmane.org/find-root.php?message_id=1204835208.47d0538897a5c%40mail.bluebottle.com&type=blog

...it seems that I was the first one who used FSF GCC to compile Ada and 
Apple GCC to compile C & link everything. Advanced Mac OS X features are 
not accessible from FSF GCC.

-- 
If you want to get to the top, you have to start at the bottom

Re: Creating and using Ada packages: need refinement

[Ludovic Brenta]

Ivan Levashew writes:

> Ludovic Brenta пишет:
>>> Adaproject seems to be unmaintained.
>>
>> What is adaproject?
> http://sourceforge.net/projects/adaprojet/
>
>> deficiencies and lack of portability of C and C++. We use Ada. We
>> don't need no stupid autotools. In simple cases, one GNAT project file
>> is sufficient. Nowadays, with gprmake, they can even handle multi-
>> language projects, so even these are "simple cases".
> BTW, is gprbuild publicly available?

TTBOMK, not yet; it was announced in September and probably released
only as part of wavefronts of GNAT Pro to customers.  It should
surface as part of GNAT GPL 2008 Edition and, maybe, GCC 4.4 or later.

OTOH, I was not talking about gprbuild.  I was talking about gprmake,
which has been part of GCC since 4.0 and is publicly available.
gprmake handles multi-language projects just fine, thank you very
much.

> http://libre.adacore.com/viewvc/trunk/gps/distrib/features?revision=122527&view=markup
>> NF-43-H216-003 gprbuild no longer packaged with GPS (2008-02-19)
> It sounds like one might discover older gprbuild version in some gps
> revision if search carefully. I didn't find it yet.

I scanned the log of the GPS sources in my monotone mirror and
gprbuild has never been part of gps.  Maybe it was delivered with gps
4.1 and 4.2 but it is not part of the GNAT GPL 2007 sources.

>> Mac OS X is much more standard than e.g. Microsoft Windows, and there
>> are people who care about it. They are on http://www.macada.org

> I didn't noticed they are using Ada in an advanced way.
> Provided that:
>
> http://news.gmane.org/find-root.php?message_id=1204835208.47d0538897a5c%40mail.bluebottle.com&type=blog
>
> ...it seems that I was the first one who used FSF GCC to compile Ada
> and Apple GCC to compile C & link everything. Advanced Mac OS X
> features are not accessible from FSF GCC.

Not yet, that is... I'm sure you'll contribute the necessary changes
to make that happen, and become a hero!

-- 
Ludovic Brenta.

Re: Creating and using Ada packages: need refinement

[Ivan Levashew]

Ludovic Brenta пишет:
>> BTW, is gprbuild publicly available?
> 
> TTBOMK, not yet; it was announced in September and probably released
> only as part of wavefronts of GNAT Pro to customers.  It should
> surface as part of GNAT GPL 2008 Edition and, maybe, GCC 4.4 or later.
> 
> OTOH, I was not talking about gprbuild.  I was talking about gprmake,
> which has been part of GCC since 4.0 and is publicly available.
> gprmake handles multi-language projects just fine, thank you very
> much.
OK, it seems to be available to the wide public in the future. I've just 
remembered that I have downloaded a nightly build of GPS 4.3.0w in 
December, 2007. gprbuild is present there! And its documentation is 
present too.
I have published it on 
http://octagram.gorodok.net/gprbuild/gprbuild_ug.html FYI.
Google can't find gprbuild_ug.html on any other website.

No mysteries anymore. Now I can see what does gprbuild pretend to be.

 > GPRbuild manages a three step build process
 >
 > * compilation phase
 >
 > * post-compilation phase (or binding)
 >
 > * linking phase

The whole idea looks good for me, but... what if I'll want once in a 
blue moon to use, for instance, gnatelim? Or maybe I would like to use 
"C++ headers => GCCXML => XSLT => thin Ada bindings" scheme? The problem 
I see here is that gprbuild aids simple building processes, but when one 
needs something beyond this scope one seems to have to deal with gpr 
projects and their extensions on his own. Locate files, compute flags, 
etc. Let's locate files at least. Can gprbuild's ability to locate files 
be "exported"?

I'm not sure if it's worth jumping on gprbuild. I think other Makefile 
replacements & additions are worth to be reviewed. Jamfile is one of the 
most visible ones.

-- 
If you want to get to the top, you have to start at the bottom

Re: Creating and using Ada packages: need refinement

[Eric Hughes]

On Mar 28, 6:00 am, Ivan Levashew <octag...@bluebottle.com> wrote:
> I think other Makefile
> replacements & additions are worth to be reviewed. Jamfile is one of the
> most visible ones.

I can offer a specific disrecommendation for Jamfile.  I had a classic
Very Bad experience with that last year.  There's a whole missing
middle of documentation--there's recipe book instructions and there's
basic implementation ones (which include the source code), but nothing
about how they hook up together.  Overall, it's not ready for medium-
sized uses.  Since you're not in the surface-usage class, expect to
learn the whole tool in its entirety and gory detail in order to
finish your task.

Having said that, I don't have an alternate to recommend you.

Eric

Re: Creating and using Ada packages: need refinement

[Georg Bauhaus]

Ivan Levashew wrote:

> The whole idea looks good for me, but... what if I'll want once in a
> blue moon to use, for instance, gnatelim? Or maybe I would like to use
> "C++ headers => GCCXML => XSLT => thin Ada bindings" scheme? The problem
> I see here is that gprbuild aids simple building processes, but when one
> needs something beyond ...


But this is beyond building Ada programs, with or without external
add-ons.  The above chain (!) from C++ headers to thin Ada
bindings, a rather special case, seems to be a good candidate
for those well known command languages that handle chains of commands...


> I'm not sure if it's worth jumping on gprbuild. I think other Makefile
> replacements & additions are worth to be reviewed. Jamfile is one of the
> most visible ones.

GNU Make alone is pretty powerful. By that I mean you
don't have to write cryptic novels in order to set things
up properly. Just use GNU Make idioms and "use case variables"
like VPATH. GNU Make is recursive. It has patterns. It has
a good manual.
  Anything else should IMHO be left to integration tools.
There are a number of these higher order programming tools.
All of: free, Free, or licensed for a fee.

There is no one big comforting Unity device I think. The
DWIM configuration machine idea is really good for marketing,
though.

Re: Creating and using Ada packages: need refinement

[Steve Whalen]

On Mar 28, 5:00 am, Ivan Levashew
> I'm not sure if it's worth jumping on gprbuild. I think other Makefile
> replacements & additions are worth to be reviewed. Jamfile is one of the
> most visible ones.

Just ignore this if it's too far out of line with what you are
wanting, but since you seem to want more control than than those tools
provide and we're in the Ada group ...

Have you considered something like BUSH? It's at:

http://www.pegasoft.ca/bush.html

BUsiness SHell (BUSH) ... "The Business Shell is different.  It's
based on a language called AdaScript TM, a subset of one of the most
powerful languages available" ...[Ada 95]

"BUSH is an all-in-one replacement for BASH, PHP, J2EE, Ruby, Python,
Perl and PSQL."

Not affiliated with Pegasoft or BUSH, but have always liked the idea
of an Ada based shell scripting language for Ada people.

Steve Whalen

Re: Creating and using Ada packages: need refinement

[Ivan Levashew]

> Not affiliated with Pegasoft or BUSH, but have always liked the idea
> of an Ada based shell scripting language for Ada people.

Yes, I had an idea of Ada-like scripting *SHELL* language. But I'm not 
satisfied with BUSH.

I have reviewed BUSH documentation.

http://www.pegasoft.ca/docs/bushtutorial.html#2.1

> => v := (2*3 + 5)/2
> => (Assuming v is a new universal_numeric variable)
> => ? v
>  5.50000000000000E+00
a surprise
Being and Ada programmer I would expect it to be integer.
Delphi has separate "/" and "div" operators for integer and floating 
point division. Ada has only one "/". I'm unhappy with the fact that "/" 
defaults to the floating point result here.

http://www.adaic.com/standards/05rm/html/RM-3-3-2.html
> The named number denotes a value of type universal_integer if the 
> type of the static_expression is an integer type. The named number 
> denotes a value of type universal_real if the type of the 
> static_expression is a real type.
I'd like "v := (2*3 + 5)/2" in BUSH behave the same way as
"v : constant := (2*3 + 5)/2" in Ada, but constantcy.
How many times did you need to deal with float types in the shell 
script? I can't remember a one. So it's better to require explicit 
typecasts here. There must be separate universal float and integer. 
Integers are not just subset of Floats.

http://www.pegasoft.ca/docs/bushtutorial.html#2.3
> The format of the SQL command, including how quoting is used, is
> determined by the database being used. BUSH will not perform file
> globbing (otherwise select count(*) would give very strange
> results!). BUSH will substitute variables with dollar sign expansion
> and the output from SQL commands can be redirected like an operating
> system command. For this reason you'll have to escape characters
> like ">" with a backslash used with SQL on the command line.
> 
> => select * from test where name \> 'c'
a pitfall
What's the difference between C's if (a = 0) {...
and BUSH's ... name > 'c' ?
I'd better choose another syntax for redirection.
Or maybe make parser a bit smarter?
=> select * from test where name > 'c' > filename
I don't know SQL, but "> filename" looks like being unable to introduce 
ambiguities. OK, I know, it's not a good solution. What else can we do? 
Let's think...

=> select * from test where name > 'c' 1> filename
It is much better, isn't it? Just require everybody to write whitespaces 
around ">", "<", etc. in SQL. Normal programmers write them anyway.

> -- export DISPLAY only if it exists
> DISPLAY : string := "undefined";
> pragma unchecked_import( shell, DISPLAY );
> if DISPLAY /= "undefined" then
>   pragma export( shell, DISPLAY );
> end if;
a dirty trick



http://www.pegasoft.ca/docs/bushref.html#3.7
All the types are lowercased. It is OK in an interactive prompt, but 
it's ugly IMO in full-sized scripts. I'd like to dupe every type in 
Mixed_Case. Or maybe let types be case-insensitive. A bit inconsistent 
but... It's not beautiful.


I'm using bash for a long time. I had some wishes regarding shell 
capabilities :
1. Directories as a first-order objects.
I'd like to write something like

=> zzz_src := tgz.extract (directory.open ("xxx/yyy/zzz.tgz"))
=> zzz_image := zzz_src.configure
=> zzz_image.make
=> zzz_destroot := zzz_image.install
=> directory.save (zzz_destroot, "~/zzz_destroot")
And let the shell take care of cleaning intermediate results: zzz_image 
was not bound to anything.
I'd like to use projects the same way. Projects are not neccessarily 
just one directory. I mean extension projects.

2. Downwards shell closures.
Shell closure is a special program like this:
#!/usr/bin/closure /var/shell-ipc/xxx 112312
Where /var/shell-ipc/xxx is a socket and 112312 is a shell closure 
identifier. Shell must create these temporary closures on demand.

I have no clear model of relationships between "internal" and "external" 
objects. Internal objects are like zzz_image. They exist somewhere but 
are not bound to any location. After they lose the last reference, they 
are subject to deletion. I thought about 'Location attribute for 
internal objects. In order to allow external utilities to deal with 
internal objects we must either "save" it to some location or deal with 
it in situ, by its current location. Downwards shell closure can't be 
saved. (It will be a continuation this way). It is usable only during 
its lifetime so one must use 'Location. 'Location will create temporary 
executable closure stub:

declare
    procedure CC_Wrapper (...) is
    begin
       ...
    end CC_Wrapper;
begin
    zzz_image := zzz_src.configure (CC => CC_Wrapper'Location);
    zzz_image.make;
end;

3. Make capabilities.
bash calls make, make calls bash, bash calls make...

One must remember the rules of escaping and quoting. Simple sequences 
without loops look the same way as they are in bash, but loops must be
written with '; \'. $() works different ways in make and bash.

build:
   for arch in $$ARCHS uni; do \
     mkdir -p Intermediate/out/$$arch; \
     mkdir -p Intermediate/out/$$arch/lib/pkgconfig; \
     cp -r Input/darwin-pkgs/ Intermediate/out/$$arch/lib/pkgconfig/; \
     ln -s "$$SDK"/* Intermediate/out/$$arch/; \
   done
   for i in Frozen/* ; do \
     ln -s ../"$$i" Intermediate/"$${i:7}" ; \
   done

Piece of my environment.
I think make is better be extension of shell. Make is usable in many 
ways, not just for compilation.

Once again:
=> zzz_src := tgz.extract (...)
=> zzz_image := zzz_src.configure
=> zzz_image.make
=> zzz_destroot := zzz_image.install
It looks make-ish, isn't it? What was make initially created for? To 
avoid recompilations and recomputations. It's a kind of optimization. I 
think it could be implemented in the scope of shell scripting. I would 
like all the gprbuild capabilities to be incorporated into the shell.

I need some time to formalize it.

-- 
If you want to get to the top, you have to start at the bottom

Re: Creating and using Ada packages: need refinement

[Steve Whalen]

The good news about BUSH (besides being written mostly in Ada) is that
it's license is GPL / GMGPL.

It doesn't seem to be receiving much work from Pegasoft, so if you
wanted, you could "fork" the project and fix the problems you see and
add  enhancements, if you have the time.

I haven't looked at the source enough to see if it would benefit
significantly from the new features in Ada 200X, but now that Ada has
it's version of "downward closure" maybe that would make it easier to
implement your "shell" downward closure (which I'm not sure I
understood, but I'm sure that's because I haven't had time to really
think about it).

Steve

Re: Creating and using Ada packages: need refinement

[Georg Bauhaus]

Ivan Levashew schrieb:
>  I'd like to make my Ada
> packages OS-agnostic but easily tunable for my OS.

Have ./configure write a tuned Makefile that hands
the right Env-Parameters to GNAT project files.
E.g. make the Makefile set a variable for choosing
the correct OS-specific directories containing
package bodies for the respective OS.

Why configure compiler switches beyond basic things?
These setting change frequently for little effect.
I don't see how autotools-AI could possibly help,
and with what.
Automake has created so many problems already, in
particular in the long run. So to demonstrate that
configure can be used with Ada, too, a simple setup
should work well. Basically, a stripped down
config.guess should really be sufficient. This is not
C where people insist on supporting broken runtimes
of the 1970s in new, portable software.

Re: Creating and using Ada packages: need refinement

[Ivan Levashew]

Georg Bauhaus пишет:
> Have ./configure write a tuned Makefile that hands
> the right Env-Parameters to GNAT project files.
> E.g. make the Makefile set a variable for choosing
> the correct OS-specific directories containing
> package bodies for the respective OS.
Yes, Makefile is to be the wrapper for the gnatmake, gnatclean etc.
And configure is to just handle all the environment variables. If 
GNATLINKFLAGS variable is present (or if it's defined in config.site), 
then it will affect @GNATMAKEFLAGS@, etc.

I need to enumerate the variables expected to be respected. Different 
Ada packages respect different environment variables. For instance, some 
package might use ${ADAC} instead of ${ADA} as supposed.

> Automake has created so many problems already, in
> particular in the long run. So to demonstrate that
> configure can be used with Ada, too, a simple setup
> should work well. Basically, a stripped down
> config.guess should really be sufficient. This is not
> C where people insist on supporting broken runtimes
> of the 1970s in new, portable software.
But I might want to include some Objective C code in my packages.

-- 
If you want to get to the top, you have to start at the bottom

Re: Creating and using Ada packages: need refinement

[Ivan Levashew]

> I need to enumerate the variables expected to be respected.
a draft:
http://en.wikibooks.org/wiki/Talk:Ada_Programming/GNU_Build_System

-- 
If you want to get to the top, you have to start at the bottom