CPAN style Ada repository

CPAN style Ada repository

[banjo]

Hi

Would there be interest in a Perl CPAN style Ada repository?

Using the best ideas from Perl's CPAN, GitHub, Debian packages,
SourceForge, Savannah, and how Go uses git.

Using git versioning, bug tracking, mirrors, smoke-testing,
packaging standards etc, to archive, package, distribute
and promote high quality Ada modules.

I could rant on the ramshackle state of the Ada ecosystem
but I'll restrain myself.

-billy

Re: CPAN style Ada repository

[Thomas Løcke]

On 11/28/2013 04:41 PM, banjo wrote:
> Would there be interest in a Perl CPAN style Ada repository?


Go and Dart handles these things more or less perfectly, IMHO.

I believe Ada would benefit greatly from having tools like those two
languages.


-- 
Thomas Løcke | thomas@12boo.net | http://12boo.net

Re: CPAN style Ada repository

[Lucretia]

On Friday, 29 November 2013 07:04:51 UTC, Thomas Løcke  wrote:
> Go and Dart handles these things more or less perfectly, IMHO.
> 
> I believe Ada would benefit greatly from having tools like those two
> languages.

There is golang.org and dartlang.org, maybe we should have adalang.org? This could handle the advertisement of the language, features, web based demo, etc. Then also link to the installer as a subdomain.

Luke.

Re: CPAN style Ada repository

[J Kimball]

On 12/12/2013 04:17 AM, Lucretia wrote:
> On Friday, 29 November 2013 07:04:51 UTC, Thomas Løcke  wrote:
>> Go and Dart handles these things more or less perfectly, IMHO.
>>
>> I believe Ada would benefit greatly from having tools like those two
>> languages.
>
> There is golang.org and dartlang.org, maybe we should have adalang.org? This could handle the advertisement of the language, features, web based demo, etc. Then also link to the installer as a subdomain.
>
> Luke.
>

http://ada-lang.org

Don't you read #ada or do you just lurk there?

Re: CPAN style Ada repository

[Lucretia]

On Friday, 13 December 2013 06:54:03 UTC, J Kimball  wrote:

> http://ada-lang.org
> 
> Don't you read #ada or do you just lurk there?

Just lurking, of course!

Re: CPAN style Ada repository

[Felix Krause]

On 2013-11-28 15:41:37 +0000, banjo said:

> Would there be interest in a Perl CPAN style Ada repository?

In general this is a great idea. There are a lot of things
to consider though. I don't think it's a good idea to launch
a site that hosts whole Ada probjects, basically because there
are already great sites for doing that, including support
for various version control systems and bug tracking.

IMHO it would make more sense to have something like the BSD
ports trees (or similarly, Homebrew for OSX): Just a list of
available libraries / tools with a unified build mechanism and
dependency resolution. The projects themselves could be hosted
elsewhere, so we'd have a repository of meta information that
is able to resolve dependencies, retrieve source code and
compile libraries.

The major problem is that from what I know, Ada code is not
very portable between compilers (even the .ads/.adb naming
convention is GNAT-specific). Should only GNAT be supported?
If not, should project be required to build on different
compilers in order to be allowed in the repository?

Of course, anything that allows open source Ada projects to
make more use of each other would improve the current
situation.

-- 
Felix Krause
http://flyx.org/

Re: CPAN style Ada repository

[Simon Wright]

Felix Krause <usenet@flyx.org> writes:

> The major problem is that from what I know, Ada code is not
> very portable between compilers (even the .ads/.adb naming
> convention is GNAT-specific).

The only other compiler I have (recent) experience of is ObjectAda,
which was quite happy to import .ads/.adb files into its library.

>                               Should only GNAT be supported?
> If not, should project be required to build on different
> compilers in order to be allowed in the repository?

A lot of potential contributors won't have access to anything other than
GNAT. And you'd have problems using Ada2012 features.

Re: CPAN style Ada repository

[Dennis Lee Bieber]

On Fri, 29 Nov 2013 20:17:24 +0000, Simon Wright <simon@pushface.org>
declaimed the following:

>Felix Krause <usenet@flyx.org> writes:
>
>> The major problem is that from what I know, Ada code is not
>> very portable between compilers (even the .ads/.adb naming
>> convention is GNAT-specific).
>
>The only other compiler I have (recent) experience of is ObjectAda,
>which was quite happy to import .ads/.adb files into its library.
>
	Not sure how difficult it would be to go /to/ Rational Ada -- but that
compiler uses an even less clear naming than GNAT...

	*.1.ada => *.ads
	*.2.ada => *.adb
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

Re: CPAN style Ada repository

[Yannick Duchêne (Hibou57)]

Le Fri, 29 Nov 2013 23:53:35 +0100, Dennis Lee Bieber  
<wlfraed@ix.netcom.com> a écrit:

> On Fri, 29 Nov 2013 20:17:24 +0000, Simon Wright <simon@pushface.org>
> declaimed the following:
>
>> Felix Krause <usenet@flyx.org> writes:
>>
>>> The major problem is that from what I know, Ada code is not
>>> very portable between compilers (even the .ads/.adb naming
>>> convention is GNAT-specific).
>>
>> The only other compiler I have (recent) experience of is ObjectAda,
>> which was quite happy to import .ads/.adb files into its library.
>>
> 	Not sure how difficult it would be to go /to/ Rational Ada -- but that
> compiler uses an even less clear naming than GNAT...
>
> 	*.1.ada => *.ads
> 	*.2.ada => *.adb

It's clear to me at least: that's probably to list specifications before  
bodies… which makes sense for Ada.

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

Re: CPAN style Ada repository

[Jeffrey Carter]

On 11/29/2013 12:22 PM, Felix Krause wrote:
>
> The major problem is that from what I know, Ada code is not
> very portable between compilers (even the .ads/.adb naming
> convention is GNAT-specific). Should only GNAT be supported?
> If not, should project be required to build on different
> compilers in order to be allowed in the repository?

In my limited experience (only dating back to 1984), well written Ada code is 
extremely portable between compilers. Usually all that is needed to port such 
Ada between compilers is to recompile.

-- 
Jeff Carter
"We use a large, vibrating egg."
Annie Hall
44

Re: CPAN style Ada repository

[Georg Bauhaus]

On 29.11.13 20:22, Felix Krause wrote:
> The major problem is that from what I know, Ada code is not
> very portable between compilers (even the .ads/.adb naming
> convention is GNAT-specific).

The 1-unit convention (.ads [+.adb +-sub.adb]) has not caused
any problem for AdaMagic compilers (including ObjectAda
mentioned by Simon). The ones I know have been rather flexible
with regard to files and compilation units.

Some problems were not so much caused by the Ada source,
but by implementation specific attributes such as 'Img (intended
for debugging, but welcome by lazy typists, I suppose) or by
using types from the standard library such as Integer. These cause
portability issues that wouldn't be there if using just 'Image or
if defining integer types to match the problem domain; other
problems were caused by OS/GCC-specific linker pragmas in source
(these problems were removed by dropping the pramgas and adding
linker switches to build scripts instead).

Are there other typical causes that render Ada code non-portable
between Ada compilers? Compiler bugs I suppose, but these cannot
always be addressed by changing the source.

FWIW, adding to GNAT the ICC Ada95 Pretty Printer is free
and can be used for checking syntax, at the very least.
Maybe the pretty printer is updated someday to match the language
that ICC Ada currently supports (Ada 2005).

Also, http://build.ada-language.com/ can be a useful resource
for making Ada software translation portable.

Re: CPAN style Ada repository

[Martin]

On Friday, November 29, 2013 10:15:07 PM UTC, Georg Bauhaus wrote:
> On 29.11.13 20:22, Felix Krause wrote:
> 
> > The major problem is that from what I know, Ada code is not
> 
> > very portable between compilers (even the .ads/.adb naming
> 
> > convention is GNAT-specific).
> 
> 
> 
> The 1-unit convention (.ads [+.adb +-sub.adb]) has not caused
> 
> any problem for AdaMagic compilers (including ObjectAda
> 
> mentioned by Simon). The ones I know have been rather flexible
> 
> with regard to files and compilation units.
> 
> 
> 
> Some problems were not so much caused by the Ada source,
> 
> but by implementation specific attributes such as 'Img (intended
> 
> for debugging, but welcome by lazy typists, I suppose) or by
> 
> using types from the standard library such as Integer. These cause
> 
> portability issues that wouldn't be there if using just 'Image or
> 
> if defining integer types to match the problem domain; other
> 
> problems were caused by OS/GCC-specific linker pragmas in source
> 
> (these problems were removed by dropping the pramgas and adding
> 
> linker switches to build scripts instead).
> 
> 
> 
> Are there other typical causes that render Ada code non-portable
> 
> between Ada compilers? Compiler bugs I suppose, but these cannot
> 
> always be addressed by changing the source.
> 
> 
> 
> FWIW, adding to GNAT the ICC Ada95 Pretty Printer is free
> 
> and can be used for checking syntax, at the very least.
> 
> Maybe the pretty printer is updated someday to match the language
> 
> that ICC Ada currently supports (Ada 2005).
> 
> 
> 
> Also, http://build.ada-language.com/ can be a useful resource
> 
> for making Ada software translation portable.


Depends how good the original programmers were...for instance, a fairly typical problem when porting XD-Ada code to any Ada95+ compiler is that XD-Ada included non-standard types in package System...and unfortunately lots of programmers didn't know or didn't care and used them widely. Sigh.

Also, a classic non-Ada programmer type of thing to do would be to use Integer / Float everywhere (or those pesky XD-Ada System types!) thinking they were using C or something...

-- Martin

Re: CPAN style Ada repository

[Randy Brukardt]

"Georg Bauhaus" <rm.dash-bauhaus@futureapps.de> wrote in message 
news:529911e9$0$6625$9b4e6d93@newsspool2.arcor-online.net...
...
> Are there other typical causes that render Ada code non-portable
> between Ada compilers? Compiler bugs I suppose, but these cannot
> always be addressed by changing the source.

With GNAT code, there is often (lazy, IMHO) use of 'Unrestricted_Access. And 
of course, lots of people use various GNAT library packages which have to be 
replaced by something else in order to port.

For Janus/Ada to GNAT, it's mostly library dependence, and as you say, 
compiler bugs. (The worst ones being where the compiler allowed something 
that shouldn't have been legal, those are often painful to remove.)

                                                Randy.

Re: CPAN style Ada repository

[Shark8]

On Friday, November 29, 2013 12:22:36 PM UTC-7, Felix Krause wrote:
> 
> The major problem is that from what I know, Ada code is not
> very portable between compilers (even the .ads/.adb naming
> convention is GNAT-specific).

Really?
I've heard tales of Ada projects being ported to different architectures and compilers w/o any source changes. (More often there are *some* changes: usually related to the hosting architecture.)

> If not, should project be required to build on different
> compilers in order to be allowed in the repository?

There *WAS* a Jenkins build server for the Ada Doom3 project -- but it appears to be offline; it had three compilers and two architectures (win & linux), IIRC. 

> Of course, anything that allows open source Ada projects to
> make more use of each other would improve the current
> situation.

Agreed.

Re: CPAN style Ada repository

[gautier_niouzes]

> The major problem is that from what I know, Ada code is not
> very portable between compilers (even the .ads/.adb naming
> convention is GNAT-specific).

If you compare with interpreted languages or languages with an unique vendor, sure, but as an open, compiled language, Ada is very portable, it not the most portable.
Consider Zip-Ada, which builds on both GNAT and ObjectAda out of the box for at least 19 OS/CPU/Compiler combinations with a single source set!...
For deatils, see:

  http://unzip-ada.sf.net/#tested

> Should only GNAT be supported?

It would be very restrictive. Perhaps you want to have flags like "Any compiler" or "GNAT only".
_________________________
Gautier's Ada programming
http://gautiersblog.blogspot.com/search/label/Ada

Re: CPAN style Ada repository

[Stephen Leake]

banjo <banjo@actrix.co.nz> writes:

> Would there be interest in a Perl CPAN style Ada repository?
>
> Using the best ideas from Perl's CPAN, GitHub, Debian packages,
> SourceForge, Savannah, and how Go uses git.

It would be a long fight to get any agreement on what is "best" from
that list!

> Using git versioning, 

Just for starters, it should be monotone, not git (or at least
Mercurial). (We're Ada, we do things _right_, not just "popular").

> bug tracking, mirrors, smoke-testing, packaging standards etc, 

The only portable package is a tar.gz of source code. And even then,
some people think they need .zip for windows, and you'd still get
arguments about Makefiles vs .gpr files vs bash scripts vs DOS scripts
... 

Of course, every package must include an Emacs Ada mode 5.0 project file
:).

> to archive, package, distribute and promote high quality Ada modules.

"high quality" is the rub; that takes expert reviewers, who have time to
read and test _every_ submission. Not going to happen without funding,
and lots of it.

Hands up; how many people think _every_ component in AdaCore's gnatcoll
is "high quality" (hint; I'm not raising my hand). How much money do
they spend on it?

On the other hand, I don't think CPAN is high quality; just large.

Much better to contribute to one of the existing packaging systems. It
would be interesting to know how many people use each. I use Debian (a
little bit) and Cygwin (a lot).

I might be persuaded to contribute Ada code to Mingw 64, but I haven't
really gotten started using that yet.

-- 
-- Stephe

Re: CPAN style Ada repository

[Jacob Sparre Andersen]

Stephen Leake wrote:
> banjo <banjo@actrix.co.nz> writes:

>> Would there be interest in a Perl CPAN style Ada repository?
>>
>> Using the best ideas from Perl's CPAN, GitHub, Debian packages,
>> SourceForge, Savannah, and how Go uses git.

> Just for starters, it should be monotone, not git (or at least
> Mercurial). (We're Ada, we do things _right_, not just "popular").
>
>> bug tracking, mirrors, smoke-testing, packaging standards etc, 
>
> The only portable package is a tar.gz of source code. And even then,
> some people think they need .zip for windows, and you'd still get
> arguments about Makefiles vs .gpr files vs bash scripts vs DOS scripts
> ...
>
> Of course, every package must include an Emacs Ada mode 5.0 project
> file :).

:-)

I've for a long time used Debian as my main consolidated Ada repository,
but as Ada 2012 has some very nice features, which make for fewer bugs,
I manage with GNAT-GPL-2013 and manual installation of libraries.  As
soon as the Ada 2012 patches appear in the Debian "gnat" package, I
intend to switch back.

It would of course be nice with an easy-to-use operating system and
compiler independent supply of Ada tools and libraries.  But how can we
do it in a way, which doesn't make it Just Another Source of Ada
Libraries?

What would it take to make most of us Ada developers contribute to this
one system?

+ Easier than making Debian packages?  (Because I haven't gotten around
  to make even a single Ada based Debian package yet.)

+ Automagically works for "all" platforms?  (I don't feel like wasting
  time on testing if my sources work on platforms I don't use.)

+ Automagically works for "all" compilers?  (We can probably get away
  with only testing for different versions of GNAT, but why limit
  ourselves?)

>> to archive, package, distribute and promote high quality Ada modules.
>
> "high quality" is the rub; that takes expert reviewers, who have time
> to read and test _every_ submission. Not going to happen without
> funding, and lots of it.

I would probably not worry as much about reviewing the submissions as on
testing something as simple as how well they build (on which platforms,
with which compilers) and pass their own internal tests.

> Hands up; how many people think _every_ component in AdaCore's
> gnatcoll is "high quality" (hint; I'm not raising my hand). How much
> money do they spend on it?

No hands up here.  It doesn't look like they spend all that much money
on it.

> Much better to contribute to one of the existing packaging systems. It
> would be interesting to know how many people use each. I use Debian (a
> little bit) and Cygwin (a lot).

The challenge with that is that a contibution to either is only that.
If one could contribute to both at the same time, it would be nice.

IIRC somebody set up a Jenkins server for building and testing Ada
projects.  That might be a good place to work from.  No need to pick
specific version control repositories or anything.  Just publish and
demonstrate working build scripts for your Ada projects.

Greetings,

Jacob
-- 
Photos from the Faroe Islands:
       http://billeder.sparre-andersen.dk/The_Faroe_Islands/

Re: CPAN style Ada repository

[Tero Koskinen]

On Sat, 30 Nov 2013 14:12:57 +0100
Jacob Sparre Andersen <jacob@jacob-sparre.dk> wrote:
> IIRC somebody set up a Jenkins server for building and testing Ada
> projects.  That might be a good place to work from.  No need to pick
> specific version control repositories or anything.  Just publish and
> demonstrate working build scripts for your Ada projects.

It was me. The Jenkins server(s) is up at http://build.ada-language.com/

I have access to three different compilers, GNAT, Janus/Ada, and
Irvine ICCAda, so I have setup them to compile various Ada projects
automatically in multiple environments.

However, unfortunately, the distributed build results are not
updated/reported currently because of Jenkins bug
https://issues.jenkins-ci.org/browse/JENKINS-20067

Once that is fixed or once I find time to switch to another CI system,
the build reports will be updating again.

-- 
Tero Koskinen - http://iki.fi/tero.koskinen/

Re: CPAN style Ada repository

[johannes falcone]

automated stuff is nice 

but simply a list of where to download and compile keys things would be a huge help

Re: CPAN style Ada repository

[Simon Wright]

johannes falcone <visphatesjava@gmail.com> writes:

> automated stuff is nice 
>
> but simply a list of where to download and compile keys things would
> be a huge help

In that case, http://www.adaic.org/ada-resources/tools-libraries/

Re: CPAN style Ada repository

[Brian Drummond]

On Sun, 01 Dec 2013 07:08:52 +0000, Simon Wright wrote:

> johannes falcone <visphatesjava@gmail.com> writes:
> 
>> automated stuff is nice
>>
>> but simply a list of where to download and compile keys things would be
>> a huge help
> 
> In that case, http://www.adaic.org/ada-resources/tools-libraries/

Who maintains and updates it?

I notice that both AVR-Ada and MSP430-Ada are missing. I can understand 
the latter as it's in its early stages and I haven't exactly publicised 
it much, but AVR-Ada is pretty well established and really ought to be 
there.

http://sourceforge.net/projects/avr-ada/
http://sourceforge.net/projects/msp430ada/

- Brian

Re: CPAN style Ada repository

[Brian Drummond]

On Sun, 01 Dec 2013 07:08:52 +0000, Simon Wright wrote:

> johannes falcone <visphatesjava@gmail.com> writes:
> 
>> automated stuff is nice
>>
>> but simply a list of where to download and compile keys things would be
>> a huge help
> 
> In that case, http://www.adaic.org/ada-resources/tools-libraries/

Who maintains and updates it?

I notice that both AVR-Ada and MSP430-Ada are missing. I can understand 
the latter as it's in its early stages and I haven't exactly publicised 
it much, but AVR-Ada is pretty well established and really ought to be 
there.

http://sourceforge.net/projects/avr-ada/
http://sourceforge.net/projects/msp430ada/

- Brian

Re: CPAN style Ada repository

[Jacob Sparre Andersen]

Brian Drummond wrote:

>> In that case, http://www.adaic.org/ada-resources/tools-libraries/
>
> Who maintains and updates it?

I think the current editor is Randy Brukardt.  You can write him at
<news@adaic.org>, in case he misses a relevant announcement here.

Greetings,

Jacob
-- 
"Politicians are a lot like diapers. They should be changed
 frequently, and for the same reasons."

Re: CPAN style Ada repository

[Jacob Sparre Andersen]

johannes falcone <visphatesjava@gmail.com> writes:

> automated stuff is nice 

https://github.com/rostgaard/Ada-development-Makefile

Far from as complete as the Ada-IC overview, but sort of automatic.

Greetings,

Jacob
-- 
»And what about homo sapiens?
 Yes, we think that would be a very good idea ...« -- not Gandhi

Re: CPAN style Ada repository

[Björn Persson]

banjo wrote:
> Would there be interest in a Perl CPAN style Ada repository?
> 
> Using the best ideas from Perl's CPAN, GitHub, Debian packages,
> SourceForge, Savannah, and how Go uses git.
> 
> Using git versioning, bug tracking, mirrors, smoke-testing,
> packaging standards etc, to archive, package, distribute
> and promote high quality Ada modules.

This might seem like a good idea, until one starts to realize the
implications.

I assume that you would want this repository to be usable on many
different operating systems, and maybe with different compilers
(because if you were planning to target only GNAT and Debian for
example, then you'd simply make Debian packages instead of proposing a
new repository). The Ada language itself is quite portable between
operating systems and compilers, but how to get the Ada code compiled
and installed is quite another story. There is no standard for how to
invoke a compiler or how to link to libraries, no standard set of
compiler options and so on. Different operating systems have different
commands for making directories and copying files, vastly different
filesystem layouts, and even differences in pathname syntax. GNAT
project files do only parts of the job, and are specific to GNAT as far
as I know.

CPAN has it easy by comparison. There is only one Perl interpreter
(probably because the language is such a hideous mess that it's
impossible to write a compatible second implementation), so they don't
need to worry about different compilers.


I recommend packaging for one of the existing distributions instead.
Come join us in Fedora, Debian or some other distribution of your
choice. Version control systems, bug trackers, build servers, mirrors
and packaging standards are already there for you (at least in Fedora),
and the packages will be just as readily available to users as any
other package.

It may seem like duplicated effort to package the same software
multiple times for different distributions, but it's actually not so
bad. Packaging for one operating system is easier than packaging for
many of them at once, so it's several smaller efforts instead of one
big effort. I took part in the Gnuada project at Sourceforge for a
while. There we tried to make RPM packages that could be built for both
Suse and Fedora. Only two target platforms, very similar and based on
the same package manager, and even that was enough to cause problems.


One thing that would help considerably, and that would be surmountable,
would be if developers of free Ada software could agree on some
conventions for how makefiles should be written. Free projects usually
have build systems made of makefiles and Gnat project files, but most of
them are too inflexible to adapt to different filesystem layouts,
support staging or allow compiler options to be customized. Packaging
is slow when packagers have to figure out how each makefile works and
often patch makefiles to get them to meet packaging standards. We could
get much more libraries and programs packaged if developers would follow
some conventions. Such conventions would need to work for mixed-language
projects as well as pure Ada projects, and for both Gnatmake and
GPRbuild.

I recommend using the Make variable names from the GNU Coding Standards
(https://www.gnu.org/prep/standards/html_node/Makefile-Conventions.html) 
and extending that with Ada-specific variables in the same style.

Developers, please support LDFLAGS for linker options, and support
CFLAGS if there is C code in your project. Stick to this naming scheme
and use "ADAFLAGS" for Ada compiler options, "GNATBINDFLAGS" for
Gnatbind options, and so on.

Support the GNU standard directory variables so that your software can
be installed in different systems with different filesystem layouts:
prefix, exec_prefix, bindir, libdir, libexecdir and all the others as
appropriate for the types of files that your project installs. Extend
with "gprdir" for GNAT project files and "alidir" for ALI files. Install
ALI files in a library-specific subdirectory of alidir, just like source
files go in a subdirectory of includedir. Support DESTDIR so that
packagers can install to a staging directory and don't have to build
packages as root.

Writing such a flexible makefile is of course nontrivial work that you
don't want to do over and over. You can avoid most of the work by using
Comfignat (https://www.rombobjörn.se/Comfignat/). Comfignat gives you
all of the above, except that limitations in Gnatmake's and GPRbuild's
command line syntax prevent it from automatically supporting LDFLAGS
and GNATBINDFLAGS when libraries are built.

This approach covers only those operating systems that are Unix-like
enough to have Make and basic commands such as cp and mkdir, but that
should include OS X, and hopefully even Windows with Cygwin or MinGW is
Unix-like enough, so it's a decent set of target platforms. (And none
of the above prevents you from also supporting some other platform by
other means.)

Björn Persson

Re: CPAN style Ada repository

[Stephen Leake]

Björn Persson <bjorn@xn--rombobjrn-67a.se> writes:

> CPAN has it easy by comparison. There is only one Perl interpreter
> (probably because the language is such a hideous mess that it's
> impossible to write a compatible second implementation), so they don't
> need to worry about different compilers.

excellent point.

> One thing that would help considerably, and that would be surmountable,
> would be if developers of free Ada software could agree on some
> conventions for how makefiles should be written. Free projects usually
> have build systems made of makefiles and Gnat project files, but most of
> them are too inflexible to adapt to different filesystem layouts,
> support staging or allow compiler options to be customized. Packaging
> is slow when packagers have to figure out how each makefile works and
> often patch makefiles to get them to meet packaging standards. We could
> get much more libraries and programs packaged if developers would follow
> some conventions. Such conventions would need to work for mixed-language
> projects as well as pure Ada projects, and for both Gnatmake and
> GPRbuild.

This is a reasonable idea; I would participate in discussions around
this. 

There's a related but orthogonal topic of Ada modes for various IDE's;
the upstream packages could contain appropriate project files for at
least some IDEs.

I'm maintaining Emacs Ada mode, and looking into improving AdaCore's GPS
to get some of the features (and vice versa). So my packages will have
Emacs Ada mode project files, and GNAT gpr files.

There is also Eclipse; are there any other reasonably popular IDEs that
Ada people use?

> I recommend using the Make variable names from the GNU Coding Standards
> (https://www.gnu.org/prep/standards/html_node/Makefile-Conventions.html) 
> and extending that with Ada-specific variables in the same style.

I'll have to study that.

> Developers, please support LDFLAGS for linker options, and support
> CFLAGS if there is C code in your project. Stick to this naming scheme
> and use "ADAFLAGS" for Ada compiler options, "GNATBINDFLAGS" for
> Gnatbind options, and so on.

Sounds reasonable

> Support the GNU standard directory variables so that your software can
> be installed in different systems with different filesystem layouts:
> prefix, exec_prefix, bindir, libdir, libexecdir and all the others as
> appropriate for the types of files that your project installs. 

I would leave "install" to the packagers; upstream Makefiles should just
build in place.

> Writing such a flexible makefile is of course nontrivial work that you
> don't want to do over and over. You can avoid most of the work by using
> Comfignat (https://www.rombobjörn.se/Comfignat/). Comfignat gives you
> all of the above, except that limitations in Gnatmake's and GPRbuild's
> command line syntax prevent it from automatically supporting LDFLAGS
> and GNATBINDFLAGS when libraries are built.

I haven't looked at this yet. But it sounds like an Ada-style
alternative to automake, which is very welcome.

-- 
-- Stephe

Re: CPAN style Ada repository

[darkestkhan]

On Thursday, December 12, 2013 4:12:52 PM UTC, Stephen Leake wrote:
> This is a reasonable idea; I would participate in discussions around
> 
> this. 
> 
> 
> 
> There's a related but orthogonal topic of Ada modes for various IDE's;
> 
> the upstream packages could contain appropriate project files for at
> 
> least some IDEs.
> 
> 
> 
> I'm maintaining Emacs Ada mode, and looking into improving AdaCore's GPS
> 
> to get some of the features (and vice versa). So my packages will have
> 
> Emacs Ada mode project files, and GNAT gpr files.
> 
> 
> 
> There is also Eclipse; are there any other reasonably popular IDEs that
> 
> Ada people use?
> 

There is also vim (I'm using it). I know quite a few people using emacs.

Re: CPAN style Ada repository

[Björn Persson]

Stephen Leake wrote:
> Björn Persson <bjorn@xn--rombobjrn-67a.se> writes:
> > Support the GNU standard directory variables so that your software
> > can be installed in different systems with different filesystem
> > layouts: prefix, exec_prefix, bindir, libdir, libexecdir and all
> > the others as appropriate for the types of files that your project
> > installs. 
> 
> I would leave "install" to the packagers; upstream Makefiles should
> just build in place.

I disagree with that for the following reasons:

· The directory variables aren't used only for copying files in the
installation step. Some of these pathnames sometimes need to be
embedded in programs so that they'll know where to find data files or
other programs.

· Some of the directory variables also need to be embedded in libraries'
usage project files. Packagers will have to patch usage projects if the
upstream build system doesn't configure them correctly, and patches are
much more of a maintenance burden than command line parameters are.

· Libraries need some source files installed, but usually not all of
the source files. At least some specifications are always needed, but
sometimes bodies are also needed, if they contain generic units or
inline subprograms. Manually keeping track of which files are needed is
difficult, especially for a packager who isn't also an upstream
developer, but the GNAT builders know which files are needed and can
install them for you.

· Packagers aren't the only ones who will build your software. Users who
download the source tarball and install locally won't like to dig files
out of the source tree manually and edit project files.

> > Writing such a flexible makefile is of course nontrivial work that
> > you don't want to do over and over. You can avoid most of the work
> > by using Comfignat (https://www.rombobjörn.se/Comfignat/).
> > Comfignat gives you all of the above, except that limitations in
> > Gnatmake's and GPRbuild's command line syntax prevent it from
> > automatically supporting LDFLAGS and GNATBINDFLAGS when libraries
> > are built.
> 
> I haven't looked at this yet. But it sounds like an Ada-style
> alternative to automake, which is very welcome.

Yes, that's a good comparison. The purpose of Comfignat is similar to
that of Automake, but the way it works is somewhat different. You
import a generic makefile instead of generating a makefile, and it
delegates dependency tracking to GPRbuild or Gnatmake.

Björn Persson

Re: CPAN style Ada repository

[Stephen Leake]

Björn Persson <bjorn@xn--rombobjrn-67a.se> writes:

> Stephen Leake wrote:
>> Björn Persson <bjorn@xn--rombobjrn-67a.se> writes:
>> > Support the GNU standard directory variables so that your software
>> > can be installed in different systems with different filesystem
>> > layouts: prefix, exec_prefix, bindir, libdir, libexecdir and all
>> > the others as appropriate for the types of files that your project
>> > installs. 
>> 
>> I would leave "install" to the packagers; upstream Makefiles should
>> just build in place.
>
> I disagree with that for the following reasons:

All valid.

Which is partly why I distribute my projects as "just include this
source dir in your project" :).

-- 
-- Stephe

Re: CPAN style Ada repository

[Jacob Sparre Andersen]

banjo <banjo@actrix.co.nz> wrote:

> Would there be interest in a Perl CPAN style Ada repository?

Something like it, yes.

I have earlier discussed the subject with Thomas Løcke and Kim Rostgaard
Christensen in terms of the tools and infrastructure provided with the
Go programming language from Google.

Step one must be to decide what the purpose of the project is.  Some
possibilities:

a) Make it easier for newcomers to Ada to get started.

b) Make it easier to find and install Open Source libraries and
   applications written in Ada.

c) Document how (and how well) Open Source libraries and applications
   written in Ada build and run on various platforms and with various
   compilers.

d) Advertise the existence of other Ada compilers than GNAT.

e) Survive, grow, and encompass all published Open Source Ada source
   texts.

I know that not all contributors to this thread weigh these purposes
equally, but I think they all have value for the Ada community as a
whole.

Based on these objectives I propose:

1) Make a "first download" package, which provides (or downloads or
   validates the existence of) a compiler and a client (developer) tool.

   (Like for Go.  A step towards objective a.)

2) Besides the "first download", the system provides "projects", which
   may be libraries, applications or a mix of both.  (A "library" is
   basically a project without any non-test executables.)  The
   collection of projects can be queried and downloaded through the
   client tool.

   (A step towards objectives a and b.)

3) All projects are required to have some built-in tests.  As a minimum
   there should be test applications which ensure that all compilation
   units in the project sources are compiled.

   (A step towards objective c.)

4) Support multiple compilers.  Tero Koskinen has both GNAT, Irvine
   ICCAda and Janus/Ada on his <http://build.ada-language.com/> site, so
   it should be possible.

   (A step towards objectives c and d.)

5) Make it easy for developers to submit new projects to the system.

   (A step towards objective e.)


Refining the proposals above:

6) Each project needs some build rules.  As we want to support multiple
   compilers (proposal 4), it makes sense to have a very simple
   (proposal 5) build rule format, which then can be compiled to build
   rules for the various supported compilers.

   The minimum requirements for the build rules might be as simple as
   three lists:
    - Which projects this project depends on.
    - Which applications are to be generated by this project.
    - Which test programs are included in the project.

7) If an up-stream project is parametrised (or uses different sources
   for different hosts/compilers/targets), our view of it is multiple
   unparametrised projects.  This will allow for simpler build rules
   (proposal 5 and 6) and at the same time simplify testing (objective c
   and proposal 3)

----------------------------------------------------------------------------

The following is a collection of various ideas for the project on a more
practical level.  These ideas are not (yet) tied properly to the
objectives listed above.


General:
========

- Source-only projects - Skip the whole problem of generating dynamic
  libraries.  Not many systems will have more than one application
  running using large parts of the same Ada library.

- Use ISO dates plus a single latin letter as version identifiers for
  projects.  This will allow about one version per hour per project.  Is
  this an unreasonable limit?

- Project naming: As Ada identifiers with the extra constraint that they
  can't end in "_" & Possible_Version_Identifier or "_" &
  Possible_Version_Identifier & "_test".  (Other constraints?)  This is
  to allow GPR files to reference either the "head" version of a project
  or a specific revision.

- Project parameters:

   + Build rules.

   + Version control link.

   + Provides: API ID's.

   + Dependencies: Both other projects in the system, API ID's _and_
     operating system specific dependencies.

   + (plus revision information)


Client (developer tool):
========================

- Keep track of which projects the developer has fetched explicitly (and
  which specific versions have been requested, where that is relevant)

- Keep track of the dependencies of the installed projects, and make
  sure they are fulfilled.

- When updating; only pull the newest versions of previously requested
  projects, when the developer hasn't asked for a specific version or
  has asked for "head".

- The Go command-line tool has (at least) the following operations: get,
  build, test, run, install.  I'm not sure I care about "run", but
  "drop" (sort-of "uninstall") and "select-compiler" (as we want to
  support more than one) would be nice additions.

Service:
========

- Generate new project versions from up-stream commits automatically.

- Test new project versions automatically as they are generated.

- Only release project versions which pass the tests on at least one
  host-compiler-target combination.

- It would be nice if it automatically could test which revisions of the
  dependencies of a project result in a working (test-passing) system.

- Should we host copies of the sources of the projects as a part of the
  service?  Jim Kimball doesn't like to do it, but I like the idea of
  fetching sources and build rules from a single location.

----------------------------------------------------------------------------

Greetings,

Jacob

PS: I like a name like "go Ada" better than "something-CPAN".
-- 
Those who can't laugh at themselves leave the job to others.

Re: CPAN style Ada repository

[Yannick Duchêne (Hibou57)]

Le Thu, 12 Dec 2013 09:23:05 +0100, Jacob Sparre Andersen  
<jacob@jacob-sparre.dk> a écrit:

> banjo <banjo@actrix.co.nz> wrote:
>
>> Would there be interest in a Perl CPAN style Ada repository?
>
> Something like it, yes.
>
> […]
>
> b) Make it easier to find and install Open Source libraries and
>    applications written in Ada.
>
> […]
>
> d) Advertise the existence of other Ada compilers than GNAT.

If “open source” is used as synonym of “gratis” (as it is usually), then  
point B and D are mostly incompatible, as all other Ada compilers are not  
gratis.

Still talking about other compilers, then a point to add would be to try  
to restrict sources to what other compilers supports at a given time, and  
I guess actually this is rather Ada 2005 and not Ada 2012 (except may be  
Janus Ada from RR Software).

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

Re: CPAN style Ada repository

[Jacob Sparre Andersen]

Yannick Duchêne wrote:
> Le Thu, 12 Dec 2013 09:23:05 +0100, Jacob Sparre Andersen
> <jacob@jacob-sparre.dk> a écrit:

>> b) Make it easier to find and install Open Source libraries and
>>    applications written in Ada.
>>
>> […]
>>
>> d) Advertise the existence of other Ada compilers than GNAT.
>
> If “open source” is used as synonym of “gratis” (as it is usually),
> then point B and D are mostly incompatible, as all other Ada compilers
> are not gratis.

I use "Open Source" as per the official definition [1].

I don't think those points are incompatible.  Although you in some cases
are not allowed to distribute Open Source software compiled with a
closed source compiler, the same can be true for compiling it with an
Open Source compiler.

> Still talking about other compilers, then a point to add would be to
> try to restrict sources to what other compilers supports at a given
> time, and I guess actually this is rather Ada 2005 and not Ada 2012
> (except may be Janus Ada from RR Software).

I don't see any point in excluding software written in Ada 2012 (or Ada
83 for that matter) as long as it is correct Ada 2012.  Showing off how
one can make good use of Ada 2012 is likely to motivate the vendors to
upgrade their offerings to support it.

Greetings,

Jacob

[1] http://opensource.org/osd
-- 
A: Yes.
>Q: Are you sure?
>>A: Because it reverses the logical flow of conversation.
>>>Q: Why is top posting frowned upon?

Re: CPAN style Ada repository

[Brian Drummond]

On Thu, 12 Dec 2013 11:26:08 +0100, Jacob Sparre Andersen wrote:

> Yannick Duchêne wrote:
>> Le Thu, 12 Dec 2013 09:23:05 +0100, Jacob Sparre Andersen
>> <jacob@jacob-sparre.dk> a écrit:

> 
>> Still talking about other compilers, then a point to add would be to
>> try to restrict sources to what other compilers supports at a given
>> time, and I guess actually this is rather Ada 2005 and not Ada 2012
>> (except may be Janus Ada from RR Software).
> 
> I don't see any point in excluding software written in Ada 2012 (or Ada
> 83 for that matter) as long as it is correct Ada 2012.  Showing off how
> one can make good use of Ada 2012 is likely to motivate the vendors to
> upgrade their offerings to support it.

Colour code the download buttons (or provide other filtering means). 
Green indicates tested successfully with multiple compilers, multiple OS. 
Perhaps gold makes imaginative use of new techniques (Ada-2012), steel 
blue (hardened and tempered) uses SPARK.

-Brian

Re: CPAN style Ada repository

[G.B.]

On 12.12.13 11:26, Jacob Sparre Andersen wrote:
> I don't see any point in excluding software written in Ada 2012 (or Ada
> 83 for that matter) as long as it is correct Ada 2012.  Showing off how
> one can make good use of Ada 2012 is likely to motivate the vendors to
> upgrade their offerings to support it.

Part of the effort would be to "webify" the PAL, I think?

Re: CPAN style Ada repository

[Jacob Sparre Andersen]

"G.B." <rm-dash-bau-haus@dash.futureapps.de> writes:

> Part of the effort would be to "webify" the PAL, I think?

That would make sense.  (For a suitable meaning of "webify". ;-)

Greetings,

Jacob
-- 
"I don't want to gain immortality in my works.
 I want to gain it by not dying."

Re: CPAN style Ada repository

[Randy Brukardt]

"Jacob Sparre Andersen" <jacob@jacob-sparre.dk> wrote in message 
news:87a9g5btj6.fsf@adaheads.sparre-andersen.dk...
> "G.B." <rm-dash-bau-haus@dash.futureapps.de> writes:
>
>> Part of the effort would be to "webify" the PAL, I think?
>
> That would make sense.  (For a suitable meaning of "webify". ;-)

The old Walnut Creek CDs had a browsable index; the version hosted at 
archive.adaic.com definitely has such indexes. So they're already 
"webified", at least at a first cut level. (Those included the PAL along 
with other stuff.) See http://archive.adaic.com/ase/.

Of course, it would be useful to have build scripts, applicability to 
various compilers (way too much free code only works with one compiler), and 
other information. There's always more that can be done.

                         Randy.