Software Engineer Seeks Compatible Cratifier

Software Engineer Seeks Compatible Cratifier

[Jeffrey R.Carter]

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

Re: Software Engineer Seeks Compatible Cratifier

[Pascal Obry]

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

Re: Software Engineer Seeks Compatible Cratifier

[Jeffrey R.Carter]

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

Re: Software Engineer Seeks Compatible Cratifier

[Pascal Obry]

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

Re: Software Engineer Seeks Compatible Cratifier

[Simon Wright]

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.

Re: Software Engineer Seeks Compatible Cratifier

[Alastair Hogge]

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

Re: Software Engineer Seeks Compatible Cratifier

[Dmitry A. Kazakov]

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

Re: Software Engineer Seeks Compatible Cratifier

[Luke A. Guest]

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

Re: Software Engineer Seeks Compatible Cratifier

[G.B.]

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?

Re: Software Engineer Seeks Compatible Cratifier

[Simon Wright]

"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)