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

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

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

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.

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

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.

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,

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

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

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
>

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

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.

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

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

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

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

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.

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