From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on ip-172-31-74-118.ec2.internal X-Spam-Level: X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.5-pre1 Path: eternal-september.org!reader02.eternal-september.org!aioe.org!pBWEO6hi52oGFheO/GY5ag.user.gioia.aioe.org.POSTED!not-for-mail From: Stephen Leake Newsgroups: comp.lang.ada Subject: Re: Suggestion about best practice with .gpr files Date: Mon, 31 May 2021 09:59:14 -0700 Organization: Aioe.org NNTP Server Message-ID: <861r9met5p.fsf@stephe-leake.org> References: NNTP-Posting-Host: pBWEO6hi52oGFheO/GY5ag.user.gioia.aioe.org Mime-Version: 1.0 Content-Type: text/plain X-Complaints-To: abuse@aioe.org User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (windows-nt) Cancel-Lock: sha1:zhF66GmPzcOzQZMS0G/A/4dPPqs= X-Notice: Filtered by postfilter v. 0.9.2 Xref: reader02.eternal-september.org comp.lang.ada:62060 List-Id: AdaMagica 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