Re: adding include path in linux

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Mon, 18 May 2009 04:01:58 -0700 (PDT), Ludovic Brenta wrote:

> Dmitry A. Kazakov wrote on cpmp.lang.ada:
>> On Mon, 18 May 2009 03:00:52 -0700 (PDT), Ludovic Brenta wrote:
>>> On May 18, 11:53�am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
>>> wrote:
>>>> Maybe, it would appropriate here.
>>
>>>> I am going to write a small portable GtkAda-based installer program for
>>>> GNAT library gpr projects. The basic idea is to get rid of ugly makefiles,
>>>> which never work as expected.
>>
>>>> The thingy should do everything just per reading lists of files to install
>>>> from a directory of sources. Then according to the file names and
>>>> extensions it will shuffle the files here and there.
>>
>>>> Some mangling of the gpr files is planned. In particular modifying "with"
>>>> paths and "for Object_Dir use" stuff etc.
>>
>>>> Generation of a messy python plug-in script is also in plan.
>>
>>>> Any suggestions?
>>
>>> Please define "portable"?
>>
>> Minimally: working under Windows and Linux.
>>
>>> Debian for one does not need a GtkAda-based installer because it
>>> already has one, called Synaptic (as well as a text-based installer
>>> called Aptitude). Most other self-respecting distributions come with
>>> both installers and a proper package management system.
>>
>> Yes, a system working only on the platform in question, like rpm.
>>
>>> So, what
>>> platform are you targetting that does not already have these?
>>
>> Technically speaking GNAT GPS.
> 
> GNAT GPS is not a platform. It runs on a platform that you have
> identified as "Windows and Linux".

In this case it is, because the library is to be integrated into GPS /
GPRBuild. Whatever runs underneath is of no interest.

> The platform provides a package
> management system (including installation and configuration
> subsystem). It would be harmful for GNAT GPS to provide another
> incompatible system.

I don't think so, because:

1. there is no packaging system covering the platform span supported by
GPS.

2. GNAT itself as well as its libraries like GtkAda are not distributed by
AdaCore using packaging systems.

3. The intended use targets low profile libraries, which are not archived
in public repositories.

> I suggest that the best use of resources, if packaging/installation is
> a problem, is to provide native installers for a selection of target
> platforms, and to make the libraries thus packaged highly visible to
> users of those platforms. For example, installers for libraries that
> use Window's or Red Hat's (since you mentioned RPM) package management
> system. That's what I do (successfully) in Debian and I have been
> encouraging others to do the same on other platforms for several
> years.

"Native installer" is exactly what I don't want. Experience shows that this
does not work. People do not care to write 100+ installers for a small
library. Should a library reach the level of use that would capture
interest of Debian distributors, then nothing should prevent you or someone
else to package it. It seems that we are talking about different
"ecological niches".

> This is in fact one area where, IMHO, portability is NOT desirable.
> The closest thing in existence is the GNU Ada Project which provides
> native packages of several libraries (and versions of GNAT) for
> multiple platforms, from a common base. But the binary packages are
> themselves platform-dependent.

That is IMO not an Ada way and not an intended use of what I am going to
write.

I think that one of the great advantages of GPS / GPRBuild is that they
finally freed us from that make-madness. (gnatmake was the first step in
that direction). I can have (and do have) Ada projects compilable on any
platform where GNAT is installed. When using GPRBuild I do not need to
patch files anymore. It is advisable for any Ada developer to design his
projects in an OS-independent manner. From what I have learnt about GNAT
installation, it seems that integration of a user library into GPS /
GPRBuild can be performed independently on that
OS-packaging-repository-configure-make nightmare.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de