From Newsgroup: comp.lang.ada

https://forum.ada-lang.io/t/2024-crate-of-the-year-awards/923/8?u=jc001

--
Jeff Carter
"I have a very small head and I had
better learn to live with it ..."
Edsger Dijkstra
158
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.ada

Le mardi 18 juin 2024 à 15:05 +0200, Jeffrey R.Carter a écrit :

https://forum.ada-lang.io/t/2024-crate-of-the-year-awards/923/8?u=jc001

The first thing would be to accept adding a GPR project file into your projects. You have rejected my PR proposing just this. How one is
supposed to build a set of unrelated Ada files?
--
  Pascal Obry /  Magny Les Hameaux (78)
  The best way to travel is by means of imagination
  http://photos.obry.net
  gpg --keyserver keys.gnupg.net --recv-key F949BD3B
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.ada

On 2024-06-18 15:40, Pascal Obry wrote:>

The first thing would be to accept adding a GPR project file into your projects. You have rejected my PR proposing just this. How one is
supposed to build a set of unrelated Ada files?

IIUC, there has to be a project file in the crate. That does not mean there has
to be a project file in my Github repository.
--
Jeff Carter
"I have a very small head and I had
better learn to live with it ..."
Edsger Dijkstra
158

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.ada

Le mardi 18 juin 2024 à 20:06 +0200, Jeffrey R.Carter a écrit :

IIUC, there has to be a project file in the crate. That does not mean
there has
to be a project file in my Github repository.

But then you impose someone to create a project file. And this would be
needed by all packager, there is not only crates around to build a
component. And moreover, you let the "packager" find the correct
options to be used which is certainly not a good solution.
That's exactly why I had proposed a PR with a project file. It
"documents" the way the code must be compiled (at least with GNAT) and installed for everyone wanting to package your components.
--
  Pascal Obry /  Magny Les Hameaux (78)
  The best way to travel is by means of imagination
  http://photos.obry.net
  gpg --keyserver keys.gnupg.net --recv-key F949BD3B
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.ada

Pascal Obry <pascal@obry.net> writes:

Le mardi 18 juin 2024 à 20:06 +0200, Jeffrey R.Carter a écrit :

IIUC, there has to be a project file in the crate. That does not mean
there has to be a project file in my Github repository.

But then you impose someone to create a project file. And this would be needed by all packager, there is not only crates around to build a
component. And moreover, you let the "packager" find the correct
options to be used which is certainly not a good solution.

That's exactly why I had proposed a PR with a project file. It
"documents" the way the code must be compiled (at least with GNAT) and installed for everyone wanting to package your components.

The crate in the index contains (amongst other things) the name of the
.gpr and a link to the source; e.g.

project-files = "minimal_containers.gpr"

[origin]
commit = "592661c64b8ad6fa40864e9584a8faa3a1d2b283"
url = "git+https://github.com/simonjwright/minimal_containers.git"

The project file is in the source.

It would be possible to 'cratify' the PragmaARCs by forking the repo and
adding an alire.toml and a .gpr - which would be very simple if there
was no particular need for special compilation switches (and one
wouldn't need compile_all.adb). But it would feel a bit daunting without
a helpful README.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.ada

On 18/06/2024 14:40, Pascal Obry wrote:

Le mardi 18 juin 2024 à 15:05 +0200, Jeffrey R.Carter a écrit :

https://forum.ada-lang.io/t/2024-crate-of-the-year-awards/923/8?u=jc001

The first thing would be to accept adding a GPR project file into your projects. You have rejected my PR proposing just this. How one is
supposed to build a set of unrelated Ada files?

alr init --lib --in-place
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.ada

"Jeffrey R.Carter" <spam.jrcarter.not@spam.acm.org.not> writes:

https://forum.ada-lang.io/t/2024-crate-of-the-year-awards/923/8?u=jc001

I'm prepared to do this, if we can agree.

I would fork your repo, and make changes/distribute from there.

I propose an alire.toml, on these lines:

name = "pragmarc"
### needs to be in lower case

description = "Utility library"

version = "4.0.0"
### you have 4 releases on Github, the current code is the 4th, I
### believe. The release needs to be in this form; I did think about
### e.g. 2024.03.23, that might work

authors = ["Jeffrey R. Carter"]
maintainers = ["Simon Wright <simon@pushface.org>"]
maintainers-logins = ["simonjwright"]
licenses = "BSD-3-Clause"

website = "https://github.com/jrcarter/PragmARC"
### is there a better one? if not, this should probably be to my fork

tags = ["utility", "library"]
### what should this list be extended to?

[build-switches]
"*".Style_Checks = "no"
### alire's style checks disagree violently with your usage!

"*".Ada_Version = "Ada12"
### this is what you specify in the code

(email: simon@pushface.org)
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.ada

On Tue, 18 Jun 2024 20:27:16 +0200, Pascal Obry wrote:

Le mardi 18 juin 2024 à 20:06 +0200, Jeffrey R.Carter a écrit :

IIUC, there has to be a project file in the crate. That does not mean
there has to be a project file in my Github repository.

But then you impose someone to create a project file. And this would be needed by all packager, there is not only crates around to build a
component. And moreover, you let the "packager" find the correct options
to be used which is certainly not a good solution.

That's exactly why I had proposed a PR with a project file. It
"documents" the way the code must be compiled (at least with GNAT) and installed for everyone wanting to package your components.

+1 for a .gpr project file to enable package maintainers; it facilitates easier to integrate Ada systems with the host system.
--
To health and anarchy
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.ada

On 2024-06-23 10:10, Alastair Hogge wrote:

On Tue, 18 Jun 2024 20:27:16 +0200, Pascal Obry wrote:

Le mardi 18 juin 2024 à 20:06 +0200, Jeffrey R.Carter a écrit :

IIUC, there has to be a project file in the crate. That does not mean
there has to be a project file in my Github repository.

But then you impose someone to create a project file. And this would be
needed by all packager, there is not only crates around to build a
component. And moreover, you let the "packager" find the correct options
to be used which is certainly not a good solution.

That's exactly why I had proposed a PR with a project file. It
"documents" the way the code must be compiled (at least with GNAT) and
installed for everyone wanting to package your components.

+1 for a .gpr project file to enable package maintainers; it facilitates easier to integrate Ada systems with the host system.

Yes, but the system must generate a parent gpr file with the target
settings. Fedora's GNAT has such a thing in a very primitive form. It
must define the target OS description, default switches, 32 vs 64 bit, architecture, availability of pragma Atomic for 64-bit scalars, some
standard libraries for the linker etc. Then the user gpr will able to
refer to these in the main gpr.

OT, the reason why I do not use Alire is because it has no upload
function. I cannot manually submit my projects each time I ship a new
version of some of them. It should support automated uploads.
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.ada

On 18.06.24 15:40, Pascal Obry wrote:

Le mardi 18 juin 2024 à 15:05 +0200, Jeffrey R.Carter a écrit :

https://forum.ada-lang.io/t/2024-crate-of-the-year-awards/923/8?u=jc001

The first thing would be to accept adding a GPR project file into your projects. You have rejected my PR proposing just this. How one is
supposed to build a set of unrelated Ada files?

Might a good README actually be better? And also stable?

The number of programming languages in production used to be really large.
So large, 400+, that a reduction project was given green light(*).
To get the number up again, is seems that the market is having every programming language multiplied by at least two build tools' description language.

As before, mostly single vendors are providing the definitions of a
respective formalism, versions, obsolescence, life cycle policies,
all included.

__
(*) Around 40 languages here. Does the number seem familiar?
--- Synchronet 3.20a-Linux NewsLink 1.114