[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: system-wide gpr files live in /usr/share but mention an?arch-dependant path



Ludovic Brenta wrote:
> Björn Persson <bjorn@xn--rombobjrn-67a.se> writes:
> > Nicolas Boulenguez wrote:
> >> I would suggest a name less generic than directories.gpr. An end-user
> >> may, for very similar reasons, have a project named directories.gpr
> >> in the current directory, and this would cause obscure
> >> errors. Something like system_library_directories.gpr?
> > 
> > Seeing that I've already renamed the file once in Fedora I'd rather
> > not rename it again now that we have a number of libraries using it
> > and a policy document that mentions the filename. On the other hand I
> > don't want it to cause trouble to users. Could you elaborate on what
> > obscure errors you think would occur?
> > 
> > The GNAT tools search for an included project file relative to the
> > including project file before they try the default project
> > directories. This means that the user's project files will use the
> > user's own directories.gpr, but installed library packages will use
> > the global directories.gpr, so it seems to me that everything will
> > work as intended.
> 
> Ada forbids two compilation units to have the same name in a closure.
> I'd be very surprised if GNAT would allow two different project files in
> a closure to have the same name; and even if this is allowed, there is a
> big potential for confusion.

I made an experiment. I put a local directories.gpr in a directory, with 
different contents from what the global directories.gpr has. Then I put a file 
called test.gpr in the same directory that started like this:

with "gtkada";
with "directories";

gtkada.gpr and the global directories.gpr are installed in /usr/lib/gnat, and 
gtkada.gpr also imports "directories". It turned out that the global 
directories.gpr was used both in gtkada.gpr and in test.gpr.

Then I changed the order of the with clauses in test.gpr:

with "directories";
with "gtkada";

Now it was the local directories.gpr that got used, even in gtkada.gpr, even 
though it wasn't in the project path from the point of view of gtkada.gpr.

Oh crap!

Apparently the GNAT tools search for a file with a matching name the first time 
it's mentioned, and if they encounter the same name again they just use the 
file they already read instead of searching on the project path again.

But what if an absolute path is used? I made gtkada.gpr import 
"/usr/lib/gnat/directories.gpr" instead of just "directories". Now the GNAT 
tools did read both files, but complained about a duplicate project name in the 
second one they read.

So the GNAT tools do indeed not allow two project files with the same name. 
Worse, if relative paths are used they don't even notice that there are two, 
and then the error messages can indeed get rather obscure. An absolute path 
makes the error messages accurate and easy to understand, but that would 
frustrate the second purpose of the file – to avoid hard-coded paths in project 
files.

OK, I agree that a less generic name would be good. I'll propose a name change 
in Fedora if Debian decides to adopt this approach. 
"system_library_directories" isn't entirely accurate though, as Bindir isn't a 
library directory. Is "system_directories" unique enough? Or maybe 
"directory_variables"?

Björn

Attachment: signature.asc
Description: This is a digitally signed message part.


Reply to: