comp.lang.ada
 help / color / mirror / Atom feed
* Suggestion about best practice with .gpr files
@ 2021-05-30 17:37 mockturtle
  2021-05-30 17:46 ` Stephen Leake
                   ` (4 more replies)
  0 siblings, 5 replies; 18+ messages in thread
From: mockturtle @ 2021-05-30 17:37 UTC (permalink / raw)


Dear.all,
I have a problem that I solved in a fairly acceptable way, but I would like to hear from you if there are some kind of "better practices" that I could use.

The problem is this: sometimes, while writing some software, I develop some packages that could be used elsewhere, so I "extract" them in a library of their own with their own project file that is "with-ed" inside the project file of the larger software.

When I "isolate" the package into its own library,  I like also to add some testing code.  The problem is that if I declare the project to be a library project (which is just natural) I cannot have an executable.  

In the past, I solved this problem by declaring the project to be a non-library one; nowadays I declare it to be a library project and then add a folder test/ with its src/ folder with the test programs and a specific project file that "with-s" the library project.  

Let me try drawing a picture relative to a library "foo" 

foolib/
...|
...+-- foolib.gpr
...+-- src/
...+-- obj/
...+-- test/
..........|
..........+--foolib_test.gpr
..........+--obj/
..........+--src/
................|
...............+-- foo_test_1.adb
...............+-- foo_test_2.adb
...............+-- foo_test_3.adb

I hope you got the idea. 

Do you have any suggestion about a different organization?  Do there exist some kind of "best practice" for this?

Thank you in advance for your help

Riccardo

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: Suggestion about best practice with .gpr files
  2021-05-30 17:37 Suggestion about best practice with .gpr files mockturtle
@ 2021-05-30 17:46 ` Stephen Leake
  2021-05-30 19:31   ` Simon Wright
  2021-05-30 17:56 ` Dmitry A. Kazakov
                   ` (3 subsequent siblings)
  4 siblings, 1 reply; 18+ messages in thread
From: Stephen Leake @ 2021-05-30 17:46 UTC (permalink / raw)


mockturtle <framefritti@gmail.com> writes:

> foolib/
> ...|
> ...+-- foolib.gpr
> ...+-- src/
> ...+-- obj/
> ...+-- test/
> ..........|
> ..........+--foolib_test.gpr
> ..........+--obj/
> ..........+--src/
> ................|
> ...............+-- foo_test_1.adb
> ...............+-- foo_test_2.adb
> ...............+-- foo_test_3.adb
>
> I hope you got the idea. 

I do something similar; I put both foolib_test.gpr and foolib.gpr in a
build directory with a Makefile, and they share an obj directory.

> Do you have any suggestion about a different organization? Do there
> exist some kind of "best practice" for this?

Certainly hiding the test code from the client is essential; other than
that I don't think it matters much.

-- 
-- Stephe

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: Suggestion about best practice with .gpr files
  2021-05-30 17:37 Suggestion about best practice with .gpr files mockturtle
  2021-05-30 17:46 ` Stephen Leake
@ 2021-05-30 17:56 ` Dmitry A. Kazakov
  2021-05-30 20:22 ` Jeffrey R. Carter
                   ` (2 subsequent siblings)
  4 siblings, 0 replies; 18+ messages in thread
From: Dmitry A. Kazakov @ 2021-05-30 17:56 UTC (permalink / raw)


On 2021-05-30 19:37, mockturtle wrote:

> Let me try drawing a picture relative to a library "foo"
> 
> foolib/
> ...|
> ...+-- foolib.gpr
> ...+-- src/
> ...+-- obj/
> ...+-- test/
> ..........|
> ..........+--foolib_test.gpr
> ..........+--obj/
> ..........+--src/
> ................|
> ...............+-- foo_test_1.adb
> ...............+-- foo_test_2.adb
> ...............+-- foo_test_3.adb
> 
> I hope you got the idea.
> 
> Do you have any suggestion about a different organization?  Do there exist some kind of "best practice" for this?

I do just same, except for the src subdirectories. I put sources in the 
corresponding root where the *.gpr is.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: Suggestion about best practice with .gpr files
  2021-05-30 17:46 ` Stephen Leake
@ 2021-05-30 19:31   ` Simon Wright
  0 siblings, 0 replies; 18+ messages in thread
From: Simon Wright @ 2021-05-30 19:31 UTC (permalink / raw)


Stephen Leake <stephen_leake@stephe-leake.org> writes:

> I do something similar; I put both foolib_test.gpr and foolib.gpr in a
> build directory with a Makefile, and they share an obj directory.

ISTR that it was forbidden for GPRs to share an object directory?

You're not alone in sharing them, GNAT-LLVM does the same. Personally I
do as OP does.

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: Suggestion about best practice with .gpr files
  2021-05-30 17:37 Suggestion about best practice with .gpr files mockturtle
  2021-05-30 17:46 ` Stephen Leake
  2021-05-30 17:56 ` Dmitry A. Kazakov
@ 2021-05-30 20:22 ` Jeffrey R. Carter
  2021-05-31  7:42   ` AdaMagica
  2021-06-01 14:38   ` Shark8
  2021-05-31 15:02 ` Maxim Reznik
  2021-05-31 20:14 ` Per Sandberg
  4 siblings, 2 replies; 18+ messages in thread
From: Jeffrey R. Carter @ 2021-05-30 20:22 UTC (permalink / raw)


On 5/30/21 7:37 PM, mockturtle wrote:
> 
> Do there exist some kind of "best practice" for this?

The best practice is not to use project files. When everything is is Ada, they 
only add unnecessary and non-portable complexity. Unnecessary complexity is a 
sign of incompetence.

The same is true of build directory structures.

-- 
Jeff Carter
"It's all right, Taggart. Just a man and a horse being hung out there."
Blazing Saddles
34

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: Suggestion about best practice with .gpr files
  2021-05-30 20:22 ` Jeffrey R. Carter
@ 2021-05-31  7:42   ` AdaMagica
  2021-05-31 16:59     ` Stephen Leake
  2021-06-01 14:38   ` Shark8
  1 sibling, 1 reply; 18+ messages in thread
From: AdaMagica @ 2021-05-31  7:42 UTC (permalink / raw)


Jeffrey R. Carter schrieb am Sonntag, 30. Mai 2021 um 22:22:16 UTC+2:
> The best practice is not to use project files.
That's a bit extreme. I remember that APEX and ObjAda both had their own ways to define their library structures for source and object files. And so has GNAT.
I don't think that there is a universal way.
> When everything is is Ada, they 
> only add unnecessary and non-portable complexity. Unnecessary complexity is a 
> sign of incompetence. 
> 
> The same is true of build directory structures. 

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: Suggestion about best practice with .gpr files
  2021-05-30 17:37 Suggestion about best practice with .gpr files mockturtle
                   ` (2 preceding siblings ...)
  2021-05-30 20:22 ` Jeffrey R. Carter
@ 2021-05-31 15:02 ` Maxim Reznik
  2021-05-31 17:07   ` Stephen Leake
  2021-05-31 20:14 ` Per Sandberg
  4 siblings, 1 reply; 18+ messages in thread
From: Maxim Reznik @ 2021-05-31 15:02 UTC (permalink / raw)


We use a dedicated folder `gnat/` to keep project files there. This has several a advantages:

* you doesn't pollute the root directory with extra files (as you see you need at least two project file - for library and for tests)
* a user is able to observe all project files in one place and pick up needed one
* if you tend to use the repo as mono-repo (or if you split the library into two), you will get much more project files (see Matreshka or VSS). So keep them in order is important
* people who don't use project files don't see them :D

The layout becomes

foolib/
...|
...+-- Makefile
...+--alire.toml
...+-- docs
...+-- gnat
...|
......+-- foo.gpr
......+-- foo_tests.gpr
...+-- source
...+-- testsuite

To simplify a new repository creation I made a template repo and keep common files there. Take a look, perhaps you find something useful there.

https://github.com/reznikmm/matreshka
https://github.com/AdaCore/VSS
https://github.com/reznikmm/template

Best regards,

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: Suggestion about best practice with .gpr files
  2021-05-31  7:42   ` AdaMagica
@ 2021-05-31 16:59     ` Stephen Leake
  2021-06-01  9:33       ` Jeffrey R. Carter
  0 siblings, 1 reply; 18+ messages in thread
From: Stephen Leake @ 2021-05-31 16:59 UTC (permalink / raw)


AdaMagica <christ-usch.grein@t-online.de> writes:

> Jeffrey R. Carter schrieb am Sonntag, 30. Mai 2021 um 22:22:16 UTC+2:
>> The best practice is not to use project files.

> That's a bit extreme. I remember that APEX and ObjAda both had their
> own ways to define their library structures for source and object
> files. And so has GNAT.

If you don't define the source and object paths in the .gpr file, you
have to define them somewhere else; not using a .gpr file does not
eliminate that complexity, it just moves it elsewhere.

You also need a place to put compiler and linker options

Using environment variables to control what a .gpr file does, for
example release vs debug, is more complex. But in a real development
environment, those are needed also.

> I don't think that there is a universal way.

Right; porting code to another compiler/build system is often not
trivial.

>> When everything is is Ada, they 
>> only add unnecessary and non-portable complexity. 

Examples, please? I don't think any of the complexity in my .gpr files
is unnecessary. I agree it complicates porting to another compiler/build
system.

>> Unnecessary complexity is a sign of incompetence.

This I agree with.

>> The same is true of build directory structures.

I have some sympathy for this; my directory trees are quite flat, but
not absolutely flat. The Java directory convention is just horrible.

I suppose if _all_ files are in one directory, that eliminates the need
for source and object paths.

But then every file must have a unique name. GNAT already requires the
package name in the file name (by default), so that's not too bad for
most Ada code, _if_ each project uses a unique root package (which is
recommended practice).

But I find it convenient to use "test_all_harness.adb" as the file name
of the main test driver for all projects; the directory determines which
project it is for, and Emacs knows what the current project is, so it
knows how to find the right "test_all_harness.adb". Similarly for
Makefile, rules.make, notes.text, etc.

Hmm. Relaxing that to "all files for one project should be in one
directory" might work well. I do have some small projects that are
structured that way. except the object dir is still separate, for
simplicity in the version control ignore file. And there are still
dependent projects, so that still requires a source or project path. And
keeping the test files separate from the main project source helps when
using tools like grep.

I also sometimes have a "devel" directory and gpr file; it contains test
utilities for client packages to use. For example, wisitoken.ads defines
several types, and wisitoken-aunit.ads defines "Check" procedures for
those types. ada-mode uses wisitoken, so an ada-mode test probably needs
wisitoken-aunit.ads, but not the wisitoken tests. So ada_mode_test.gpr
withs wisitoken_devel.gpr, which includes wisitoken/devel, but not
wisitoken/test.

-- 
-- Stephe

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: Suggestion about best practice with .gpr files
  2021-05-31 15:02 ` Maxim Reznik
@ 2021-05-31 17:07   ` Stephen Leake
  0 siblings, 0 replies; 18+ messages in thread
From: Stephen Leake @ 2021-05-31 17:07 UTC (permalink / raw)


Maxim Reznik <reznikmm@gmail.com> writes:

> foolib/
> ...|
> ...+-- Makefile
> ...+--alire.toml
> ...+-- docs
> ...+-- gnat
> ...|
> ......+-- foo.gpr
> ......+-- foo_tests.gpr
> ...+-- source
> ...+-- testsuite

I used to maintain a project that was compiled with gnat for general
development and initial testing, and ObjectAda for final testing and
release. So there was an "object_ada" directory parallel to the "gnat"
directory. But I also found that the Makefiles differed enough that they
were in those directories as well; shared rules are in a "rules.make"
file.

Similar issues arise when maintaining distribution files for several OS
versions.

And "docs" are source, just in a different language. Why are they in a
separate directory?

If you are grepping for all occurences of variable "foo", you want to
search the .texi and .ad[sb] files at the same time.

-- 
-- Stephe

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: Suggestion about best practice with .gpr files
  2021-05-30 17:37 Suggestion about best practice with .gpr files mockturtle
                   ` (3 preceding siblings ...)
  2021-05-31 15:02 ` Maxim Reznik
@ 2021-05-31 20:14 ` Per Sandberg
  4 siblings, 0 replies; 18+ messages in thread
From: Per Sandberg @ 2021-05-31 20:14 UTC (permalink / raw)


Well that's the way I have been doing it for 20+ years with some small 
twists.
GPR_PROJECT_PATH points here:
!foolib/
!...|
!...+-- foolib.gpr
!...+-- src/
!........|foolib.ads
!...+-- lib/
!...+-- .obj/
!...+-- test/
!..........|
!..........+--foolib-test.gpr
!..........+-- .obj/
!..........+-- bin/
!..........+-- src/
!................|
!...............+-- foolib-tests-test_1.adb
!...............+-- foolib-tests-test_2.adb
!...............+-- foolib-tests-test_3.adb
!foxlib/
!application1/
!application2/

Then the experience i quite similar to what you get with an "eclipse 
workspace".
But with the capability to a lot of other structural exercises, such as 
having a baseline ReadOnly workspace and then using GPR_PROJECT_PATH to 
point first to a private workspace and then the baseline.

/Persan

On 30/05/2021 19:37, mockturtle wrote:
> Dear.all,
> I have a problem that I solved in a fairly acceptable way, but I would like to hear from you if there are some kind of "better practices" that I could use.
> 
> The problem is this: sometimes, while writing some software, I develop some packages that could be used elsewhere, so I "extract" them in a library of their own with their own project file that is "with-ed" inside the project file of the larger software.
> 
> When I "isolate" the package into its own library,  I like also to add some testing code.  The problem is that if I declare the project to be a library project (which is just natural) I cannot have an executable.
> 
> In the past, I solved this problem by declaring the project to be a non-library one; nowadays I declare it to be a library project and then add a folder test/ with its src/ folder with the test programs and a specific project file that "with-s" the library project.
> 
> Let me try drawing a picture relative to a library "foo"
> 
> foolib/
> ...|
> ...+-- foolib.gpr
> ...+-- src/
> ...+-- obj/
> ...+-- test/
> ..........|
> ..........+--foolib_test.gpr
> ..........+--obj/
> ..........+--src/
> ................|
> ...............+-- foo_test_1.adb
> ...............+-- foo_test_2.adb
> ...............+-- foo_test_3.adb
> 
> I hope you got the idea.
> 
> Do you have any suggestion about a different organization?  Do there exist some kind of "best practice" for this?
> 
> Thank you in advance for your help
> 
> Riccardo
> 

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: Suggestion about best practice with .gpr files
  2021-05-31 16:59     ` Stephen Leake
@ 2021-06-01  9:33       ` Jeffrey R. Carter
  2021-06-04  7:48         ` Björn Lundin
  0 siblings, 1 reply; 18+ messages in thread
From: Jeffrey R. Carter @ 2021-06-01  9:33 UTC (permalink / raw)


On 5/31/21 6:59 PM, Stephen Leake wrote:
> AdaMagica <christ-usch.grein@t-online.de> writes:
> 
>> Jeffrey R. Carter schrieb am Sonntag, 30. Mai 2021 um 22:22:16 UTC+2:
> 
>>> When everything is is Ada, they
>>> only add unnecessary and non-portable complexity.
> 
> Examples, please? I don't think any of the complexity in my .gpr files
> is unnecessary. I agree it complicates porting to another compiler/build
> system.

To develop S/W in Ada, you have to know

* Ada
* the CLI/shell syntax
* the compiler syntax and options

The compiler knows the dependencies among the units that make up a project, and 
every compiler I've used has the ability to do a build, recompiling units that 
need it, so there is no need for an additional tool to do this, as there is with C.

If I have a project Project, it will be in directory Project, which contains the 
source code and the compiler artifacts. It will also contain a one-line script 
that invokes the compiler to build Project with the desired options.

This works fine and is mostly compiler agnostic. Avoiding the unnecessary 
complexity of a build-directory structure is essential to this approach.

Adding an additional tool (gprbuild) with its own syntax (project files) to this 
is clearly adding unnecessary complexity.

If Project is a library, and there are more than a few test programs, I will 
also have a Test subdirectory for them and their build script(s).

I see no need for a compilation-order tool such as make or grpbuild, since the 
compiler already does that. (Gprbuild is supposed to be a better alternative to 
make, so using both seems like insanity to me.)

-- 
Jeff Carter
"Violence is the last refuge of the incompetent."
Foundation
151

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: Suggestion about best practice with .gpr files
  2021-05-30 20:22 ` Jeffrey R. Carter
  2021-05-31  7:42   ` AdaMagica
@ 2021-06-01 14:38   ` Shark8
  1 sibling, 0 replies; 18+ messages in thread
From: Shark8 @ 2021-06-01 14:38 UTC (permalink / raw)


On Sunday, May 30, 2021 at 2:22:16 PM UTC-6, Jeffrey R. Carter wrote:
> On 5/30/21 7:37 PM, mockturtle wrote: 
> > 
> > Do there exist some kind of "best practice" for this?
> The best practice is not to use project files. When everything is is Ada, they 
> only add unnecessary and non-portable complexity. Unnecessary complexity is a 
> sign of incompetence.

True; Ada's structuring is such that a project-file is *almost* unnecessary. I remember reading, when doing some research on build-systems, someone remarking that "build-systems are the consequence of using a language not meant for engineering." -- Given this, the general lack of needing a "build-system" for Ada is a good sign, and a testament to how Ada really *is* meant for Software Engineering.

That said, the place where Ada isn't quite up to the task is configurations, which is primarily what GPR files are used for; I've done some initial work on re-purposing Ada's generics as a "project file". (It could use a restricted set of acceptable parameters and "ASIS-processing" them such that user-inputs could be queried/provided automatically [hence the restriction on formal-parameter types].)

> 
> The same is true of build directory structures. 

I have come to deeply despise using the file-system as the repository for sources, along with "magic" environment-variables.
There are TONS of advantages that could be had with a database-based system; see: http://users.ece.utexas.edu/~perry/work/papers/icsm87.pdf and https://www.mindprod.com/project/scid.html
Yes, more design-work up-front, but it yields better properties... just like how sorting a collection allows you to have search-functions that are faster than one-at-a-time linear.

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: Suggestion about best practice with .gpr files
  2021-06-01  9:33       ` Jeffrey R. Carter
@ 2021-06-04  7:48         ` Björn Lundin
  2021-06-04  8:14           ` Dmitry A. Kazakov
                             ` (2 more replies)
  0 siblings, 3 replies; 18+ messages in thread
From: Björn Lundin @ 2021-06-04  7:48 UTC (permalink / raw)


Den 2021-06-01 kl. 11:33, skrev Jeffrey R. Carter:
> The compiler knows the dependencies among the units that make up a 
> project, and every compiler I've used has the ability to do a build, 
> recompiling units that need it, so there is no need for an additional 
> tool to do this, as there is with C.

I can tell that you never used Alsys Ada on Aix then.
It would tell you if a file was obsolete - which it became by
* changing it
* compile its spec (if it was a body)
* compile a spec which it directly or indirectly is dependent on


so - just by compiling some spec, you would obsolete another body.
And there was no such thing as recompilation.
So the whole system was built with korn-shell files stating

ada compile file_a_spec.ada
ada compile file_b_spec.ada
ada compile file_c_spec.ada

ada compile file_a_body.ada
ada compile file_b_body.ada
ada compile file_c_body.ada

and if file_a_spec.ada later on did a 'with' on file_b_spec.ada
you would need to change that korn-shell script to read

ada compile file_b_spec.ada
ada compile file_a_spec.ada
ada compile file_c_spec.ada

...

instead


For windows we had Object Ada (7.?)

It would recompile all file if they belonged to the same object libraray.

We have a hierchal structrure so we can compile code (common utilities) 
into a root object librery, and application specific code to children of 
that root

if you did changed in application layer, it would recompile changes in 
that layer - but not in the root layer.

So - we had to have corresponding bat files stating
ada compile file_a_spec.ada
....



So migrating to Gnat was a great relief.
We did use the -i switch of gnatmake and 2000 lines of tcl-glue code
to get the object files where we wanted them; to krep the hierchal 
structure. Worked very well for 15 years, then project files were
good enough to support all our requirements.
We now have basically just a bash-script calling on gprbuild with 15-20 
gprfiles. much simpler.
And the syntax for setting switches is great

we support
AIX 5,6,7
Win 2003,2008,20012,2016,2019  32/64 bit
Linux debain/ubuntu/redhat/centos on intel64 and arm64
and some playing around with
Freeebsd/macp-pc32/mac-intel64

on that we support Oracle/Postgressql/MS-sql-server
And 3 different ways of doing IPC (pipes/sem+shared mem/rabbitMQ)

and 15-20 different flavours of gnat (mostly pro, but also GPL and FSF 
on some platforms)

Sofar we only deliver on gnat pro, but I test with GPL and FSF as well.

So - the scenario handling of gpr file is just great,
the above will give you quite some combinations.
and some code cannot be compiled on all platforms,
like big-endian/little-endian record layouts.

Controlling source-file directories via gpr is much easier than anything 
we had before.

So - yes if you have small projects - fine you don't need project files.
if you have millions of lines of code - then you tend to like them.


-- 
Björn

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: Suggestion about best practice with .gpr files
  2021-06-04  7:48         ` Björn Lundin
@ 2021-06-04  8:14           ` Dmitry A. Kazakov
  2021-06-04  9:18           ` Jeffrey R. Carter
  2021-06-04 12:52           ` Simon Wright
  2 siblings, 0 replies; 18+ messages in thread
From: Dmitry A. Kazakov @ 2021-06-04  8:14 UTC (permalink / raw)


On 2021-06-04 09:48, Björn Lundin wrote:

> So - yes if you have small projects - fine you don't need project files.
> if you have millions of lines of code - then you tend to like them.

I fully agree. Also when on top of that you have multiple targets. gpr 
is really great help.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: Suggestion about best practice with .gpr files
  2021-06-04  7:48         ` Björn Lundin
  2021-06-04  8:14           ` Dmitry A. Kazakov
@ 2021-06-04  9:18           ` Jeffrey R. Carter
  2021-06-04  9:47             ` Björn Lundin
  2021-06-04 12:52           ` Simon Wright
  2 siblings, 1 reply; 18+ messages in thread
From: Jeffrey R. Carter @ 2021-06-04  9:18 UTC (permalink / raw)


On 6/4/21 9:48 AM, Björn Lundin wrote:
> 
> I can tell that you never used Alsys Ada on Aix then.

It's true I never used Alsys on Aix. My only use of Alsys was to supply some 
existing units to test an early version of the PC compiler (which discovered a 
compiler error).

I have used a wide variety of compilers in the last 37 years, and all of them 
had the ability to automatically build, recompiling obsolete units, without an 
extra compilation-order tool.

I have also worked on a number of very large projects, and all of them that were 
all-Ada could have been built solely using the compiler and simple shell scripts.

The important qualification in my claim is that the project must be all Ada. 
When you decide to include things like

> on that we support Oracle/Postgressql/MS-sql-server
> And 3 different ways of doing IPC (pipes/sem+shared mem/rabbitMQ)

then you add complications that this approach cannot deal with.

-- 
Jeff Carter
"I soiled my armor, I was so scared."
Monty Python & the Holy Grail
71

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: Suggestion about best practice with .gpr files
  2021-06-04  9:18           ` Jeffrey R. Carter
@ 2021-06-04  9:47             ` Björn Lundin
  0 siblings, 0 replies; 18+ messages in thread
From: Björn Lundin @ 2021-06-04  9:47 UTC (permalink / raw)


Den 2021-06-04 kl. 11:18, skrev Jeffrey R. Carter:
> he important qualification in my claim is that the project must be all 
> Ada. When you decide to include things like
> 
>> on that we support Oracle/Postgressql/MS-sql-server
>> And 3 different ways of doing IPC (pipes/sem+shared mem/rabbitMQ)
> 
> then you add complications that this approach cannot deal with.


Well, using a database and IPC mechanisms is not really unheard of in
systems development. Especially not when it is an administrative system,
and not embedded.

-- 
Björn

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: Suggestion about best practice with .gpr files
  2021-06-04  7:48         ` Björn Lundin
  2021-06-04  8:14           ` Dmitry A. Kazakov
  2021-06-04  9:18           ` Jeffrey R. Carter
@ 2021-06-04 12:52           ` Simon Wright
  2021-06-04 14:53             ` Björn Lundin
  2 siblings, 1 reply; 18+ messages in thread
From: Simon Wright @ 2021-06-04 12:52 UTC (permalink / raw)


Björn Lundin <b.f.lundin@gmail.com> writes:

> So the whole system was built with korn-shell files stating

I once did some work porting a Solaris system to Unix. They had migrated
to GNAT, but compilation was managed using a set of c-shell scripts
whose maintainer (one of the project managers told me) had made them his
life's work.

This would have been about 1999, so I had to use gnatmake, and I'm not
even sure whether project files existed, but it was _such_ an
improvement.

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: Suggestion about best practice with .gpr files
  2021-06-04 12:52           ` Simon Wright
@ 2021-06-04 14:53             ` Björn Lundin
  0 siblings, 0 replies; 18+ messages in thread
From: Björn Lundin @ 2021-06-04 14:53 UTC (permalink / raw)


Den 2021-06-04 kl. 14:52, skrev Simon Wright:
> Björn Lundin <b.f.lundin@gmail.com> writes:
> 
>> So the whole system was built with korn-shell files stating
> 
> I once did some work porting a Solaris system to Unix. They had migrated
> to GNAT, but compilation was managed using a set of c-shell scripts
> whose maintainer (one of the project managers told me) had made them his
> life's work.

Yeah - but in our case everybody hated them.
Quite some of my colleges had worked on VAX/VMS and the DEC Ada compiler
They say it had 'recompile *' which worked.

This AIX port with Alsys did not.
It had some kind of internal database to keep state of compiled files.
And sometimes it locked up - and it was not fun to fiddle around to 
unlock it just to be able to compile.
I MUCH prefer gnats file model - even if I know other here suggests a db 
is better.

> 
> This would have been about 1999, so I had to use gnatmake, and I'm not
> even sure whether project files existed, but it was _such_ an
> improvement.
> 

I ported our system around 2003 to gnat - first AIX then windows.
And porting to other targets having the same compiler makes it so much 
easier.


I do understand that maintainer.
My tcl glue was really good (he says shamelessly)
Taht means that it worked, and nobody needed to understand it.
Or learn tcl - which in the long run was one reason to move to gpr-files.

Sitting on a solution that nobody knows how to fix if it breaks is no fun.

-- 
Björn

^ permalink raw reply	[flat|nested] 18+ messages in thread

end of thread, other threads:[~2021-06-04 14:53 UTC | newest]

Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-05-30 17:37 Suggestion about best practice with .gpr files mockturtle
2021-05-30 17:46 ` Stephen Leake
2021-05-30 19:31   ` Simon Wright
2021-05-30 17:56 ` Dmitry A. Kazakov
2021-05-30 20:22 ` Jeffrey R. Carter
2021-05-31  7:42   ` AdaMagica
2021-05-31 16:59     ` Stephen Leake
2021-06-01  9:33       ` Jeffrey R. Carter
2021-06-04  7:48         ` Björn Lundin
2021-06-04  8:14           ` Dmitry A. Kazakov
2021-06-04  9:18           ` Jeffrey R. Carter
2021-06-04  9:47             ` Björn Lundin
2021-06-04 12:52           ` Simon Wright
2021-06-04 14:53             ` Björn Lundin
2021-06-01 14:38   ` Shark8
2021-05-31 15:02 ` Maxim Reznik
2021-05-31 17:07   ` Stephen Leake
2021-05-31 20:14 ` Per Sandberg

comp.lang.ada

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://archive.legitdata.co/comp.lang.ada

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V1 comp.lang.ada comp.lang.ada/ https://archive.legitdata.co/comp.lang.ada \
		comp.lang.ada
	public-inbox-index comp.lang.ada

Example config snippet for mirrors.


AGPL code for this site: git clone http://7fh6tueqddpjyxjmgtdiueylzoqt6pt7hec3pukyptlmohoowvhde4yd.onion/public-inbox.git