Re: Suggestion about best practice with .gpr files

[Stephen Leake <stephen_leake@stephe-leake.org>]

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