From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,de92eb048dc3c019 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news3.google.com!news4.google.com!border1.nntp.dca.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!newsfeed.kolumbus.fi!feeder2.news.jippii.net!reader1.news.jippii.net!53ab2750!not-for-mail From: Tapio Kelloniemi Subject: Re: Library file locations (was: Debian Policy for Ada, Second Edition) References: <87acbl8hc9.fsf@ludovic-brenta.org> Newsgroups: comp.lang.ada Message-ID: <36ZTf.1851$ay4.142@reader1.news.jippii.net> Date: Tue, 21 Mar 2006 20:11:43 GMT NNTP-Posting-Host: 217.30.176.187 X-Complaints-To: newsmaster@saunalahti.com X-Trace: reader1.news.jippii.net 1142971903 217.30.176.187 (Tue, 21 Mar 2006 22:11:43 EET) NNTP-Posting-Date: Tue, 21 Mar 2006 22:11:43 EET Organization: Saunalahti Customer Xref: g2news1.google.com comp.lang.ada:3529 Date: 2006-03-21T20:11:43+00:00 List-Id: Ludovic Brenta wrote: >Tapio Kelloniemi writes: >>>In particular, /usr/local is, by definition, for use by the system >>>administrator, and therefore falls outside the scope of any policy >>>defined by the operating system. >> >> Why GCC then looks for headers in /usr/local/include? Because many packages >> are installed in /usr/local by sysadmins and because /usr/local/include >> is in GCC's default search path, other packages can link against >> packages installed by admin without using absolute paths. Has anyone ever >> seen C code like: >> #include "/usr/local/include/readline/readline.h" > >No but I often see: > >gcc -c -I/usr/local/include foo.c This -I is redundant and must be treated as somebody else's problem. >> What comes to setting ADA_PROJECT_PATH, I think it is just setting >> one more redundant environment variable. Editing a text file is much >> more elegant solution. > >But you would normally set ADA_PROJECT_PATH from within a Makefile, so >your objection is weak. I don't think that /usr/local is very non-standard location for installing software. Actually if I daily used a system where there is a package manager provided by the distro, I would not install programs compiled by myself in the /usr hierarchy. You know better than I what happens if a sysadmin installs a package in /usr which overwrites a file already installed by the distro. Therefore it is good practice to install under /usr/local to prevent messing up the system's package management, and for other reasons as well. This is why /usr/local should be supported automatically or at least easily. What comes to setting ADA_PROJECT_PATH in a Makefile: Imagine that I have installed some Ada library under /usr/local (the distro provides a precompiled binary, but I want to enable a feature X required by package A). Then I compile A. If the library and the package A were written in C, I would do the following to compile A: ./configure && make && make install As they are written in Ada, I do: ./configure --with-additional-ada-project-path=/usr/local/share/ada/adainclude And what if the configure script does not support the above mentioned option? I would have to edit Makefiles, possibly run automake, etc. If the compilation process happens to be automated, I must write some nasty sed scripts to do the job. -- Tapio