* [gentoo-commits] gentoo commit in xml/htdocs/proj/en/prog_lang/ada: dev_reference.xml
@ 2007-10-05 20:51 George Shapovalov (george)
0 siblings, 0 replies; 6+ messages in thread
From: George Shapovalov (george) @ 2007-10-05 20:51 UTC (permalink / raw
To: gentoo-commits
george 07/10/05 20:51:32
Modified: dev_reference.xml
Log:
some more contents, divided topics by chapters
Revision Changes Path
1.3 xml/htdocs/proj/en/prog_lang/ada/dev_reference.xml
file : http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/en/prog_lang/ada/dev_reference.xml?rev=1.3&view=markup
plain: http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/en/prog_lang/ada/dev_reference.xml?rev=1.3&content-type=text/plain
diff : http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/en/prog_lang/ada/dev_reference.xml?r1=1.2&r2=1.3
Index: dev_reference.xml
===================================================================
RCS file: /var/cvsroot/gentoo/xml/htdocs/proj/en/prog_lang/ada/dev_reference.xml,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- dev_reference.xml 29 Sep 2007 20:20:19 -0000 1.2
+++ dev_reference.xml 5 Oct 2007 20:51:32 -0000 1.3
@@ -44,22 +44,24 @@
<dt><b>Ada libraries</b></dt>
<dd>
These are built for every installed gnat and profile-dependent files are
- installed to profile specific dirs, similarly to those of gnat, however they
- go in a "library place". This is handled automatically by gnat.eclass, inner
+ installed to profile specific dirs, similarly to those of gnat, except that they
+ go in a "library place". This is handled automatically by <c>gnat.eclass</c>, inner
workings of which are discussed below.
</dd>
<dt><b>Executables/other programs</b></dt>
- <dd>The stuff that is to be executed directly or otherwise is not supposed to be linked
- against. The prominent examples would be gps, c2ada, etc. These require no special
- treatment and can be built in a regular way with any active compiler or can
- depend on a particular variant. One particular issue should be observed however.
- If the execuables link against any of the
- profile-specific Ada libraries, when user switches gnat profile the particular
- binary versions of these libs will become unavailable. In fact, the linker will
- attempt to select the library by name and will try to link against the binary
- incompatible variant, resulting in execution failure. To resolve this, such binaries
- should be compiled with LD_RUN_PATH defined and containing the locations of the
- needed variants of the libs.
+ <dd>
+ The stuff that is to be executed directly or otherwise is not supposed to be linked
+ against. The prominent examples would be <c>gps</c>, <c>c2ada</c>, etc.
+ These require no special
+ treatment and can be built in a regular way with any active compiler or can
+ depend on a particular variant. One particular issue should be observed however.
+ If the execuables link against any of the
+ profile-specific Ada libraries, when user switches gnat profile the particular
+ binary versions of these libs will become unavailable. In fact, the linker will
+ attempt to select the library by name and will try to link against the binary
+ incompatible variant, resulting in execution failure. To resolve this, such binaries
+ should be compiled with <c>LD_RUN_PATH</c> defined and containing the locations of the
+ needed variants of the libs.
</dd>
</dl>
<p>
@@ -69,9 +71,14 @@
</p>
</body>
</section>
+ </chapter>
+
+
+ <chapter>
+ <title>gnatbuild.eclass and eselect-gnat</title>
<section>
- <title>gnatbuild.eclass and eselect-gnat</title>
+ <title>General notes.</title>
<body>
<p>
The <c>gnatbuildeclass</c> has been modelled after the <c>toolchain.eclass</c>,
@@ -87,9 +94,98 @@
It is possible they change it again to GPL-3 and FSF will likely want to do so as well.
Therefore attention needs to be paid to the licenses when these packages are updated.
</p>
+
+ <p>
+ <c>gnat</c> (both versions) can be considered a "yet another gcc frontend", therefore
+ it is built similarly to other <c>gcc</c> based languages. There is, however, a significant
+ distinction. It may be argued, that Ada is a "real language", in the sense that it
+ requires an Ada-enabled compiler to build itself. This makes the build procedure
+ significantly different from, e.g., <c>gpc</c> or <c>gdc</c> in that we first
+ need to provide a bootstrap compiler and then setup a bootstrap environment.
+ In practice, the bootstraps need to be created only once, as <c>gcc</c> (and <c>gnat</c>)
+ internally
+ build itself twice (stage1 and stage2) and then build the final binary and libs with
+ stage2. Plus, so far, all the new versions of gcc could be built with the oldest at that time
+ backend of gnat - 3.4. If, however, a version of <c>gcc</c> is released that cannot
+ be built with an old bootstrap (for example, the transition from 2.8 to the later versions
+ was problemmatic), a new one may need to be issued.
+ </p>
+
+ <p>
+ If you take a look at the <c>src_compile</c>, you will notice that all the code dealing
+ with running <c>configure</c> and <c>make</c> is preceded by the block setting many
+ env vars. Such as (here and everywhere you can refere to the appropriate eclass or ebuild
+ in portage to see all of the code):
+ </p>
+ <pre caption="Setting up bootstrap environment in gnatbuild.eclass">
+ <comment> # Set some paths to our bootstrap compiler.</comment>
+ export <ident>PATH</ident>=<const>"${GNATBOOT}/bin:${PATH}"</const>
+ <comment># !ATTN! the *installed* compilers have ${PN} as part of their
+ # LIBPATH, while the *bootstrap* uses hardset "gnatgcc" in theirs
+ # (which is referenced as GNATLIB below)</comment>
+ <ident>GNATLIB</ident>=<const>"${GNATBOOT}/lib/gnatgcc/${BOOT_TARGET}/${BOOT_SLOT}"</const>
+
+ export CC="${GNATBOOT}/bin/gnatgcc"
+ export INCLUDE_DIR="${GNATLIB}/include"
+ export LIB_DIR="${GNATLIB}"
+ export LDFLAGS="-L${GNATLIB}"
+ ...
+ </pre>
+
+ <p>
+ These setting serve the purpose of letting the gnat build scripts find the bootstrap
+ compiler, so that we do not have to depend on having some version of Ada-enabled
+ <c>gcc</c> already installed on the system. While pretty plain, this part may get somewhat
+ tricky. What vars you need to set or avoid depends on the version of toolchain
+ the build host has active. The most "abusive" package in the toolchain was traditionally
+ <c>binutils</c>. In fact there were many bugs reporting build failures with <c>configure</c>
+ complaining that <c>CC</c> is
+ unable to find <c>collect1</c> or some other part of the bootstrap compiler. The most
+ common cause of these bugs was related to an old version of <c>binutils</c> having been
+ installed on user's computer. Correspondingly, it was necessary to force gnat to depend
+ on a appropriately recent version of <c>binutils</c>. Fortunately, it seems that toolschain
+ has largerly stabilized in the last year or so, as this has not been necessary for
+ quite a while.
+ </p>
+
+
+ <p>
+ </p>
+ </body>
+ </section>
+
+ <section>
+ <title>Install locations</title>
+ <body>
+ <p>
+ To be completed.
+ </p>
+ </body>
+ </section>
+
+ <section>
+ <title>eselect-gnat workings</title>
+ <body>
+ <p>
+ To be completed.
+ </p>
</body>
</section>
</chapter>
+
+
+ <chapter>
+ <title>gnat.eclass and libraries</title>
+ <section>
+ <title>Overview</title>
+ <body>
+ <p>
+ To be completed.
+ </p>
+ </body>
+ </section>
+ </chapter>
+
</guide>
<!-- vim: set tabstop=2: -->
--
gentoo-commits@gentoo.org mailing list
^ permalink raw reply [flat|nested] 6+ messages in thread
* [gentoo-commits] gentoo commit in xml/htdocs/proj/en/prog_lang/ada: dev_reference.xml
@ 2007-10-05 21:54 George Shapovalov (george)
0 siblings, 0 replies; 6+ messages in thread
From: George Shapovalov (george) @ 2007-10-05 21:54 UTC (permalink / raw
To: gentoo-commits
george 07/10/05 21:54:21
Modified: dev_reference.xml
Log:
typo and formatting fixes
Revision Changes Path
1.4 xml/htdocs/proj/en/prog_lang/ada/dev_reference.xml
file : http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/en/prog_lang/ada/dev_reference.xml?rev=1.4&view=markup
plain: http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/en/prog_lang/ada/dev_reference.xml?rev=1.4&content-type=text/plain
diff : http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/en/prog_lang/ada/dev_reference.xml?r1=1.3&r2=1.4
Index: dev_reference.xml
===================================================================
RCS file: /var/cvsroot/gentoo/xml/htdocs/proj/en/prog_lang/ada/dev_reference.xml,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- dev_reference.xml 5 Oct 2007 20:51:32 -0000 1.3
+++ dev_reference.xml 5 Oct 2007 21:54:20 -0000 1.4
@@ -81,7 +81,7 @@
<title>General notes.</title>
<body>
<p>
- The <c>gnatbuildeclass</c> has been modelled after the <c>toolchain.eclass</c>,
+ The <c>gnatbuild.eclass</c> has been modelled after the <c>toolchain.eclass</c>,
similarly providing multiple SLOTs tracking the gcc backend variations. One additional
"complication" that we have in Ada case is that there are two related, however different
compilers available, as mentioned above. These are provided as separate packages,
@@ -118,18 +118,18 @@
in portage to see all of the code):
</p>
<pre caption="Setting up bootstrap environment in gnatbuild.eclass">
- <comment> # Set some paths to our bootstrap compiler.</comment>
- export <ident>PATH</ident>=<const>"${GNATBOOT}/bin:${PATH}"</const>
- <comment># !ATTN! the *installed* compilers have ${PN} as part of their
- # LIBPATH, while the *bootstrap* uses hardset "gnatgcc" in theirs
- # (which is referenced as GNATLIB below)</comment>
+ <comment># Set some paths to our bootstrap compiler.</comment>
+ export <ident>PATH</ident>=<const>"${GNATBOOT}/bin:${PATH}"</const>
+ <comment># !ATTN! the *installed* compilers have ${PN} as part of their
+ # LIBPATH, while the *bootstrap* uses hardset "gnatgcc" in theirs
+ # (which is referenced as GNATLIB below)</comment>
<ident>GNATLIB</ident>=<const>"${GNATBOOT}/lib/gnatgcc/${BOOT_TARGET}/${BOOT_SLOT}"</const>
- export CC="${GNATBOOT}/bin/gnatgcc"
- export INCLUDE_DIR="${GNATLIB}/include"
- export LIB_DIR="${GNATLIB}"
- export LDFLAGS="-L${GNATLIB}"
- ...
+ export <ident>CC</ident>=<const>"${GNATBOOT}/bin/gnatgcc"</const>
+ export <ident>INCLUDE_DIR</ident>=<const>"${GNATLIB}/include"</const>
+ export <ident>LIB_DIR</ident>=<const>"${GNATLIB}"</const>
+ export <ident>LDFLAGS</ident>=<const>"-L${GNATLIB}"</const>
+ ...
</pre>
<p>
--
gentoo-commits@gentoo.org mailing list
^ permalink raw reply [flat|nested] 6+ messages in thread
* [gentoo-commits] gentoo commit in xml/htdocs/proj/en/prog_lang/ada: dev_reference.xml
@ 2007-10-08 15:09 George Shapovalov (george)
0 siblings, 0 replies; 6+ messages in thread
From: George Shapovalov (george) @ 2007-10-08 15:09 UTC (permalink / raw
To: gentoo-commits
george 07/10/08 15:09:27
Modified: dev_reference.xml
Log:
another update; added disclaimer, brought formatting closer to guidelines
Revision Changes Path
1.5 xml/htdocs/proj/en/prog_lang/ada/dev_reference.xml
file : http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/en/prog_lang/ada/dev_reference.xml?rev=1.5&view=markup
plain: http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/en/prog_lang/ada/dev_reference.xml?rev=1.5&content-type=text/plain
diff : http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/en/prog_lang/ada/dev_reference.xml?r1=1.4&r2=1.5
Index: dev_reference.xml
===================================================================
RCS file: /var/cvsroot/gentoo/xml/htdocs/proj/en/prog_lang/ada/dev_reference.xml,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- dev_reference.xml 5 Oct 2007 21:54:20 -0000 1.4
+++ dev_reference.xml 8 Oct 2007 15:09:26 -0000 1.5
@@ -1,123 +1,123 @@
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
-<guide link="dev_reference.xml" lang="en">
+<guide link="dev_reference.xml" lang="en" disclaimer="draft">
- <title>Developer reference: Internal structure and organization of Ada packages.</title>
- <author title="Author">
- <mail link="george@gentoo.org">George Shapovalov</mail>
- </author>
-
- <abstract>
- This is a guide to internal workings of the gnat and gnatbuild eclasses and eselect-gnat module,
- as well as an authoritative reference to packaging principles of Ada libs and other
- related packages.
- </abstract>
-
- <version>1.0</version>
- <date>28 Sep 2007</date>
-
- <chapter>
- <title>Overview</title>
-
- <section>
- <title>Introduction</title>
- <body>
- <p>
- Before you start on the internals of the Ada packages you may want to
- go through the <uri link="ada_ug.xml">user guide</uri> in case you are not familiar with
- how to activate the chosen gnat profile and where to look for the important files.
- </p>
- <p>
- Ada related packages can be divided into three important categories:
- </p>
- <dl>
- <dt><b>Compilers and packages that directly extend them.</b></dt>
- <dd>
- Currently two closely related "brands" are supported:
- <c>gnat-gcc</c> released by FSF and <c>gnat-gpl</c>, the
- AdaCore version. The primary example of the "extending" package would
- be asis, as it is closely tied to a particular version of compiler
- and installs directly to the same locations where the specs and libs
- of the corresponding gnat go. The packages in this category should use the
- <c>gnatbuild.eclass</c>.
- </dd>
- <dt><b>Ada libraries</b></dt>
- <dd>
- These are built for every installed gnat and profile-dependent files are
- installed to profile specific dirs, similarly to those of gnat, except that they
- go in a "library place". This is handled automatically by <c>gnat.eclass</c>, inner
- workings of which are discussed below.
- </dd>
- <dt><b>Executables/other programs</b></dt>
- <dd>
- The stuff that is to be executed directly or otherwise is not supposed to be linked
- against. The prominent examples would be <c>gps</c>, <c>c2ada</c>, etc.
- These require no special
- treatment and can be built in a regular way with any active compiler or can
- depend on a particular variant. One particular issue should be observed however.
- If the execuables link against any of the
- profile-specific Ada libraries, when user switches gnat profile the particular
- binary versions of these libs will become unavailable. In fact, the linker will
- attempt to select the library by name and will try to link against the binary
- incompatible variant, resulting in execution failure. To resolve this, such binaries
- should be compiled with <c>LD_RUN_PATH</c> defined and containing the locations of the
- needed variants of the libs.
- </dd>
- </dl>
- <p>
- The profiles are switched via eselect-gnat module, the usual way. Its internal workings
- are also discussed in the chapter describing
- <c>gnatbuild.eclass</c>.
- </p>
- </body>
- </section>
- </chapter>
-
-
- <chapter>
- <title>gnatbuild.eclass and eselect-gnat</title>
-
- <section>
- <title>General notes.</title>
- <body>
- <p>
- The <c>gnatbuild.eclass</c> has been modelled after the <c>toolchain.eclass</c>,
- similarly providing multiple SLOTs tracking the gcc backend variations. One additional
- "complication" that we have in Ada case is that there are two related, however different
- compilers available, as mentioned above. These are provided as separate packages,
- <c>dev-lang/gnat-gcc</c> for FSF's Ada and <c>dev-lang/gnat-gpl</c> for the one by
- AdaCore.
- </p>
- <warn>Maintainer, beware! The last one has changed the license from GMGPL to pure GPL no
- so long ago.</warn>
- <p>
- It is possible they change it again to GPL-3 and FSF will likely want to do so as well.
- Therefore attention needs to be paid to the licenses when these packages are updated.
- </p>
-
- <p>
- <c>gnat</c> (both versions) can be considered a "yet another gcc frontend", therefore
- it is built similarly to other <c>gcc</c> based languages. There is, however, a significant
- distinction. It may be argued, that Ada is a "real language", in the sense that it
- requires an Ada-enabled compiler to build itself. This makes the build procedure
- significantly different from, e.g., <c>gpc</c> or <c>gdc</c> in that we first
- need to provide a bootstrap compiler and then setup a bootstrap environment.
- In practice, the bootstraps need to be created only once, as <c>gcc</c> (and <c>gnat</c>)
- internally
- build itself twice (stage1 and stage2) and then build the final binary and libs with
- stage2. Plus, so far, all the new versions of gcc could be built with the oldest at that time
- backend of gnat - 3.4. If, however, a version of <c>gcc</c> is released that cannot
- be built with an old bootstrap (for example, the transition from 2.8 to the later versions
- was problemmatic), a new one may need to be issued.
- </p>
-
- <p>
- If you take a look at the <c>src_compile</c>, you will notice that all the code dealing
- with running <c>configure</c> and <c>make</c> is preceded by the block setting many
- env vars. Such as (here and everywhere you can refere to the appropriate eclass or ebuild
- in portage to see all of the code):
- </p>
- <pre caption="Setting up bootstrap environment in gnatbuild.eclass">
+<title>Developer reference: Internal structure and organization of Ada packages.</title>
+<author title="Author">
+ <mail link="george@gentoo.org">George Shapovalov</mail>
+</author>
+
+<abstract>
+This is a guide to internal workings of the gnat and gnatbuild eclasses and eselect-gnat module,
+as well as an authoritative reference to packaging principles of Ada libs and other
+related packages.
+</abstract>
+
+<version>1.0</version>
+<date>28 Sep 2007</date>
+
+<chapter>
+<title>Overview</title>
+
+ <section>
+ <title>Introduction</title>
+ <body>
+ <p>
+ Before you start on the internals of the Ada packages you may want to
+ go through the <uri link="ada_ug.xml">user guide</uri> in case you are not familiar with
+ how to activate the chosen gnat profile and where to look for the important files.
+ </p>
+ <p>
+ Ada related packages can be divided into three important categories:
+ </p>
+ <dl>
+ <dt><b>Compilers and packages that directly extend them.</b></dt>
+ <dd>
+ Currently two closely related "brands" are supported:
+ <c>gnat-gcc</c> released by FSF and <c>gnat-gpl</c>, the
+ AdaCore version. The primary example of the "extending" package would
+ be <c>asis</c>, as it is closely tied to a particular version of compiler
+ and installs directly to the same locations where the specs and libs
+ of the corresponding gnat go. The packages in this category should use the
+ <c>gnatbuild.eclass</c>.
+ </dd>
+ <dt><b>Ada libraries</b></dt>
+ <dd>
+ These are built for every installed gnat and their profile-dependent files are
+ installed to profile specific dirs, similarly to those of gnat, except that they
+ go in a "library place". This is handled automatically by <c>gnat.eclass</c>, inner
+ workings of which are discussed below.
+ </dd>
+ <dt><b>Executables/other programs</b></dt>
+ <dd>
+ The stuff that is to be executed directly or otherwise is not supposed to be linked
+ against. The prominent examples would be <c>gps</c>, <c>c2ada</c>, etc.
+ These require no special
+ treatment and can be built in a regular way with any active compiler or can
+ depend on a particular variant. One particular issue should be observed however.
+ If the execuables link against any of the
+ profile-specific Ada libraries, when user switches gnat profile the particular
+ binary versions of these libs will become unavailable. In fact, the linker will
+ attempt to select the library by name and will try to link against the binary
+ incompatible variant, resulting in execution failure. To resolve this, such binaries
+ should be compiled with <c>LD_RUN_PATH</c> defined and containing the locations of the
+ needed variants of the libs.
+ </dd>
+ </dl>
+ <p>
+ The profiles are switched via eselect-gnat module, the usual way. Its internal workings
+ are also discussed in the chapter describing
+ <c>gnatbuild.eclass</c>.
+ </p>
+ </body>
+ </section>
+</chapter>
+
+
+<chapter>
+<title>gnatbuild.eclass and eselect-gnat</title>
+
+ <section>
+ <title>General notes.</title>
+ <body>
+ <p>
+ The <c>gnatbuild.eclass</c> has been modelled after the <c>toolchain.eclass</c>,
+ similarly providing multiple SLOTs tracking the gcc backend variations. One additional
+ "complication" that we have in Ada case is that there are two related, however different
+ compilers available, as mentioned above. These are provided as separate packages,
+ <c>dev-lang/gnat-gcc</c> for FSF's Ada and <c>dev-lang/gnat-gpl</c> for the one by
+ AdaCore.
+ </p>
+ <warn>Beware! The last one has changed the license from GMGPL to pure GPL no
+ so long ago.</warn>
+ <p>
+ It is possible they change it again to GPL-3 and FSF will likely want to do so as well.
+ Therefore attention needs to be paid to the licenses when these packages are updated.
+ </p>
+
+ <p>
+ <c>gnat</c> (both versions) can be considered a "yet another gcc frontend", therefore
+ it is built similarly to other <c>gcc</c> based languages. There is, however, a significant
+ distinction. It may be argued, that Ada is a "real language", in the sense that it
+ requires an Ada-enabled compiler to build itself. This makes the build procedure
+ significantly different from, e.g., <c>gpc</c> or <c>gdc</c> in that we first
+ need to provide a bootstrap compiler and then setup a bootstrap environment.
+ In practice, the bootstraps need to be created only once, as <c>gcc</c> (and <c>gnat</c>)
+ internally
+ build itself twice (stage1 and stage2) and then build the final binary and libs with
+ stage2. Plus, so far, all the new versions of gcc could be built with the oldest at that time
+ backend of gnat - 3.4. If, however, a version of <c>gcc</c> is released that cannot
+ be built with an old bootstrap (for example, the transition from 2.8 to the later versions
+ was problemmatic), a new one may need to be issued.
+ </p>
+
+ <p>
+ If you take a look at the <c>src_compile</c>, you will notice that all the code dealing
+ with running <c>configure</c> and <c>make</c> is preceded by the block setting many
+ env vars. Such as (here and everywhere you can refere to the appropriate eclass or ebuild
+ in portage to see all of the code):
+ </p>
+ <pre caption="Setting up bootstrap environment in gnatbuild.eclass">
<comment># Set some paths to our bootstrap compiler.</comment>
export <ident>PATH</ident>=<const>"${GNATBOOT}/bin:${PATH}"</const>
<comment># !ATTN! the *installed* compilers have ${PN} as part of their
@@ -129,62 +129,312 @@
export <ident>INCLUDE_DIR</ident>=<const>"${GNATLIB}/include"</const>
export <ident>LIB_DIR</ident>=<const>"${GNATLIB}"</const>
export <ident>LDFLAGS</ident>=<const>"-L${GNATLIB}"</const>
- ...
- </pre>
+ ... </pre>
- <p>
- These setting serve the purpose of letting the gnat build scripts find the bootstrap
- compiler, so that we do not have to depend on having some version of Ada-enabled
- <c>gcc</c> already installed on the system. While pretty plain, this part may get somewhat
- tricky. What vars you need to set or avoid depends on the version of toolchain
- the build host has active. The most "abusive" package in the toolchain was traditionally
- <c>binutils</c>. In fact there were many bugs reporting build failures with <c>configure</c>
- complaining that <c>CC</c> is
- unable to find <c>collect1</c> or some other part of the bootstrap compiler. The most
- common cause of these bugs was related to an old version of <c>binutils</c> having been
- installed on user's computer. Correspondingly, it was necessary to force gnat to depend
- on a appropriately recent version of <c>binutils</c>. Fortunately, it seems that toolschain
- has largerly stabilized in the last year or so, as this has not been necessary for
- quite a while.
- </p>
-
-
- <p>
- </p>
- </body>
- </section>
-
- <section>
- <title>Install locations</title>
- <body>
- <p>
- To be completed.
- </p>
- </body>
- </section>
-
- <section>
- <title>eselect-gnat workings</title>
- <body>
- <p>
- To be completed.
- </p>
- </body>
- </section>
- </chapter>
-
-
- <chapter>
- <title>gnat.eclass and libraries</title>
- <section>
- <title>Overview</title>
- <body>
- <p>
- To be completed.
- </p>
- </body>
- </section>
- </chapter>
+ <p>
+ These settings serve the purpose of letting the gnat build scripts find the bootstrap
+ compiler, so that we do not have to depend on having some version of Ada-enabled
+ <c>gcc</c> already installed on the system. While pretty plain, this part may get somewhat
+ tricky. What vars you need to set or avoid depends on the version of toolchain
+ the build host has active. The most "abusive" package in the toolchain was traditionally
+ <c>binutils</c>. In fact there were many bugs reporting build failures with <c>configure</c>
+ complaining that <c>CC</c> is
+ unable to find <c>collect1</c> or some other part of the bootstrap compiler. The most
+ common cause of these bugs was related to having an old version of <c>binutils</c>
+ installed on user's computer. Correspondingly, it was necessary to force gnat to depend
+ on a appropriately recent version of <c>binutils</c>. Fortunately, it seems that toolschain
+ has largerly stabilized in the last year or so, as this has not been necessary for
+ quite a while.
+ </p>
+ </body>
+ </section>
+
+ <section>
+ <title>Partitioning of the src_* functions.</title>
+ <body>
+
+ <p>
+ Lets take a look at some other <c>gnatbuild.eclass</c> internals. One can notice,
+ that all the <c>src_*</c> functions are partitioned in semi-independent sections,
+ as per the <uri link="">eclass guide</uri>. For example the <c>src_unpack</c>
+ has the following form:
+ </p>
+ <pre caption="gnatbuild_src_unpack structure">
+<comment># common unpack stuff</comment>
+gnatbuild_src_unpack() {
+ debug-print-function ${FUNCNAME} $@
+ [ -z <const>"$1"</const> ] && gnatbuild_src_unpack all
+
+ while [ <const>"$1"</const> ]; do
+ case $1 in
+ base_unpack)
+ unpack ${A}
+ pax-mark E $(find ${GNATBOOT} -name gnat1)
+
+ cd ${S}
+ <comment># patching gcc sources, following the toolchain</comment>
+ EPATCH_MULTI_MSG=<const>"Applying Gentoo patches ..."</const> \
+ epatch <const>"${FILESDIR}"</const>/patches/*.patch
+ ...
+ ;;
+
+ common_prep)
+ <comment># Prepare the gcc source directory</comment>
+ cd <const>"${S}/gcc"</const>
+ touch cstamp-h.in
+ ...
+ ;;
+
+ all)
+ gnatbuild_src_unpack base_unpack common_prep
+ ;;
+ esac
+ shift
+ done
+}
+ </pre>
+ <p>
+ This allows the subsections to be called independently from within overriding
+ function, such as would be an ebuild's <c>src_unpack</c> in this case. For example
+ <c>gnat-gpl-3.4.5.2005.ebuild</c> has the following in its <c>src_unpack</c>:
+ </p>
+ <pre caption="gnat-gpl-3.4.5.2005.ebuild's src_unpack">
+src_unpack() {
+ gnatbuild_src_unpack base_unpack
+
+ <comment># prep gcc sources for Ada</comment>
+ mv <const>"${GNATSOURCE}/src/ada" "${S}/gcc"</const>
+ cd <const>"${S}"</const>
+ epatch ${WORKDIR}/${PN}-gcc-${SLOT}.diff
+
+ gnatbuild_src_unpack common_prep
+
+ <comment># one of the converted gcc->gnatgcc in common_prep needs to stay gcc in
+ # fact in this version</comment>
+ sed -i -e <const>'s:(Last3 = "gnatgcc"):(Last3 = "gcc"):' "${S}/gcc/ada/makegpr.adb"</const>
+}
+ </pre>
+ <p>
+ <c>gnat_src_compile</c> and <c>gnat_src_install</c> are partitioned in a similar
+ way, allowing easy modifications to be performed at every step. Although,
+ as compilers from both FSF and ACT are becoming more unified,
+ this is rarely necessary in later versions.
+ </p>
+ </body>
+ </section>
+
+ <section>
+ <title>SLOTs and virtuals.</title>
+ <body>
+ <p>
+ Gentoo has long had support for parallel istallation of different major package
+ versions. Yes, I am talking about the famous SLOT mechanism. As here we are dealing with
+ multiple compiler variants that are supposed to be code-compatible, it only makes sense
+ to make a good use of this mechanism. It only needed to be modified to accept multiple
+ package names in our case. As all the SLOT "inner workings" are done right in the
+ eclass/ebuild code, there is nothing special about it. All what was necessary to do,
+ was to extend SLOT logic to accept proper package names.
+ </p>
+
+ <p>
+ The important part of getting SLOTs right is to use suitable naming conventon. After
+ much discussion in <uri link="">bug #..</uri> the following naming scheme was adopted:
+ <c>${PN}-${GCCVER}.${ACTVer}</c> (may be followed by the usual -rX for Gentoo specific
+ revisions). Here
+ </p>
+
+ <table>
+ <tr>
+ <th>${PN}</th>
+ <th>
+ Stands for the package name. Right now we have <c>gnat-gcc</c> for FSF's variant
+ and <c>gnat-gpl</c> for the one by AdaCore. More may be added, should we try to add
+ some other Ada compiler to the tree.
+ </th>
+ </tr>
+
+ <tr>
+ <th>${GCCVer}</th>
+ <th>
+ The gcc backend version. Something like <c>3.4.6</c> or <c>4.2.0</c>. This part is
+ split in a way similar to how it is done in <c>toolchain.eclass</c> to obtain
+ <c>GCCMAJOR</c> .. <c>GCCRELEASE</c> vars. The "in-package" part of qualifier
+ (denoted as the SLOT, to keep it compatible with the "usial way") is determined
+ solely by this var and ecuals (as in <c>toolchain</c>) <c>${GCCBRANCH}</c>.
+ While ACT omits this qualifier in its <c>gnat</c> versions, it is necessary to
+ have it supplied for consistency and proper SLOT calculation.
+ </th>
+ </tr>
+
+ <tr>
+ <th>${ACTVer}</th>
+ <th>
+ The Ada-specific part of the version. The name got "inspired" by ACT variants
+ always (so far) coming with some ACT specific lable. For example
+ <c>gnat-2006</c>. In the <c>gnat-gcc</c> case this part is empty.
+ </th>
+ </tr>
+ </table>
+
+ <p>
+ Thus, the possible examples of "fully qualified" compiler names are:
+ </p>
+ <table>
+ <tr>
+ <th>gnat-gcc-4.2.0</th>
+ <th>
+ <c>gnat-gcc</c> - an FSF version of <c>gnat</c> compiler, released
+ along with the <c>4.2.0</c> version of <c>gcc</c>.
+ </th>
+ </tr>
+
+ <tr>
+ <th>gnat-gpl-3.4.6.2006-r1</th>
+ <th>
+ An AdaCore's (<c>gnat-gpl</c>) version of <c>gnat</c> based on <c>gcc-3.4.6</c>
+ backend with the Ada specific code as in <c>gnat-gpl-2006</c>, Gentoo specific
+ revision <c>-r1</c>.
+ </th>
+ </tr>
+ </table>
+
+ <p>
+ As with <c>gcc</c>, the code produced by compiler is only binary compatible
+ within the same major version (SLOT). While theoretically one can try combining
+ object files produced by <c>gnat-gpl</c> to those produced by <c>gnat-gcc</c>
+ having identical backend version, such combinations are not supported. One must
+ also be aware of potential differences in the produced <c>ali</c> files.
+ As such, both <c>${PN}-${SLOT}</c> components are defining the "operational SLOT"
+ or profile specification. Moreover, a fully qualified profile name will contain
+ an additional component - <c>${ARCH</c> to allow for the possibility of crosscompilation.
+ However the description of this is left to the section dealing with <c>eselect-gnat</c>
+ internals.
+ </p>
+
+ <p>
+ As is often the case with packages providing similar functionality, we provide a virtual
+ that tracks various <c>gnat</c> versions: <c>virtual.gnat</c>. This is a "new style"
+ (that is, resembpling a regular package) virtual that tracks the <c>gcc</c> backend
+ versions, the <c>3.4</c>, <c>4.1</c> and <c>4.2</c> are provided as of now.
+ Also, as Ada-2005 standard has been recently approved, some packages are starting to
+ require and Ada-2005 capable compiler (of which only <c>gnat-gpl-2007</c> can be considered
+ to be providing a reasonably complete subset of Ada-2005 functionality at this moment).
+ It becomes necessary to provide another vortual: <c>virtual/ada</c> that may be populated
+ with <c>ada-1983</c>, <c>ada-1995</c> and <c>ada-2005</c>, provdiding dependencies on
+ appropriate versions of <c>gnat</c>.
+ </p>
+ </body>
+ </section>
+
+ <section>
+ <title>Install locations</title>
+ <body>
+ <p>
+ The installation procedure mimics (again) that of <c>gcc</c>. The only principal
+ difference (at the time of this writing) is that <c>gnat</c> compilers have
+ been already transitioned
+ to make use of <c>$(get_libdir)</c> where proper, while <c>toolchain</c> has not
+ done so yet. The following global vars are defined to manage the install locations:
+ </p>
+
+ <pre caption="gnat install locations">
+ <comment># set our install locations</comment>
+ PREFIX=${GNATBUILD_PREFIX:-/usr} <comment># not sure we need this hook, but may be..</comment>
+LIBPATH=${PREFIX}/$(get_libdir)/${PN}/${CTARGET}/${SLOT}
+LIBEXECPATH=${PREFIX}/libexec/${PN}/${CTARGET}/${SLOT}
+INCLUDEPATH=${LIBPATH}/include
+BINPATH=${PREFIX}/${CTARGET}/${PN}-bin/${SLOT}
+DATAPATH=${PREFIX}/share/${PN}-data/${CTARGET}/${SLOT}
+<comment># ATTN! the one below should match the path defined in eselect-gnat module</comment>
+CONFIG_PATH=<const>"/usr/share/gnat/eselect"</const>
+gnat_config_file=<const>"${D}/${CONFIG_PATH}/${CTARGET}-${PN}-${SLOT}"</const>
+ </pre>
+
+ <p>Lets go over these locations in more detail.</p>
+ <table>
+ <tr>
+ <th>Path/variable</th>
+ <th>Description</th>
+ </tr>
+
+ <tr>
+ <th><c>BINPATH</c></th>
+ <th>
+ This is where the libraries are installed. The <c>.so</c> files and such.
+ The variable itself also serves as a top location for <c>INCLUDEPATH</c>
+ </th>
+ </tr>
+
+ <tr>
+ <th><c>LIBEXECPATH</c></th>
+ <th>
+ As per FHS, the location of "other executables". Needs to be on the <c>PATH</c>
+ as well. Like <c>gcc</c>, <c>gnat</c> keeps here the compiler driver related
+ files: <c>cc1</c>, <c>collect2</c> and <c>gnat1</c>.
+ </th>
+ </tr>
+
+ <tr>
+ <th><c>LIBPATH</c></th>
+ <th>
+ This is where the libraries are installed. The <c>.so</c> files and such.
+ The variable itself also serves as a top location for <c>INCLUDEPATH</c>
+ </th>
+ </tr>
+
+ <tr>
+ <th><c>INCLUDEPATH</c></th>
+ <th>
+ Specs go here. Following <c>toolchain</c> this resides under <c>LIBPATH</c>.
+ The main reason is that, unlike with the libs, we want to keep specs for every
+ compiler variant separate.
+ </th>
+ </tr>
+
+ <tr>
+ <th><c>DATAPATH</c></th>
+ <th>
+ Man, info, locale files. Again, these may differ between <c>gnat</c> variants,
+ so keep them separate.
+ </th>
+ </tr>
+
+ <tr>
+ <th><c>CONFIG_PATH</c></th>
+ <th>
+ Where data describing these install location is stored for the <c>gnat.eselect</c>
+ module. The <c>gnat_config_file</c> points to the file containing the profile-specific
+ data.
+ </th>
+ </tr>
+ </table>
+
+ </body>
+ </section>
+
+ <section>
+ <title>eselect-gnat workings</title>
+ <body>
+ <p>
+ To be completed.
+ </p>
+ </body>
+ </section>
+</chapter>
+
+
+<chapter>
+<title>gnat.eclass and libraries</title>
+
+ <section>
+ <title>Overview</title>
+ <body>
+ <p>
+ To be completed.
+ </p>
+ </body>
+ </section>
+</chapter>
</guide>
--
gentoo-commits@gentoo.org mailing list
^ permalink raw reply [flat|nested] 6+ messages in thread
* [gentoo-commits] gentoo commit in xml/htdocs/proj/en/prog_lang/ada: dev_reference.xml
@ 2007-10-08 16:13 George Shapovalov (george)
0 siblings, 0 replies; 6+ messages in thread
From: George Shapovalov (george) @ 2007-10-08 16:13 UTC (permalink / raw
To: gentoo-commits
george 07/10/08 16:13:39
Modified: dev_reference.xml
Log:
formatting fixes
Revision Changes Path
1.6 xml/htdocs/proj/en/prog_lang/ada/dev_reference.xml
file : http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/en/prog_lang/ada/dev_reference.xml?rev=1.6&view=markup
plain: http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/en/prog_lang/ada/dev_reference.xml?rev=1.6&content-type=text/plain
diff : http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/en/prog_lang/ada/dev_reference.xml?r1=1.5&r2=1.6
Index: dev_reference.xml
===================================================================
RCS file: /var/cvsroot/gentoo/xml/htdocs/proj/en/prog_lang/ada/dev_reference.xml,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- dev_reference.xml 8 Oct 2007 15:09:26 -0000 1.5
+++ dev_reference.xml 8 Oct 2007 16:13:38 -0000 1.6
@@ -174,7 +174,7 @@
cd ${S}
<comment># patching gcc sources, following the toolchain</comment>
EPATCH_MULTI_MSG=<const>"Applying Gentoo patches ..."</const> \
- epatch <const>"${FILESDIR}"</const>/patches/*.patch
+ epatch <const>"${FILESDIR}"</const>/patches/*.patch
...
;;
@@ -210,21 +210,23 @@
gnatbuild_src_unpack common_prep
<comment># one of the converted gcc->gnatgcc in common_prep needs to stay gcc in
- # fact in this version</comment>
+ # fact in this version</comment>
sed -i -e <const>'s:(Last3 = "gnatgcc"):(Last3 = "gcc"):' "${S}/gcc/ada/makegpr.adb"</const>
-}
- </pre>
+} </pre>
+
<p>
- <c>gnat_src_compile</c> and <c>gnat_src_install</c> are partitioned in a similar
- way, allowing easy modifications to be performed at every step. Although,
- as compilers from both FSF and ACT are becoming more unified,
- this is rarely necessary in later versions.
+ <c>gnat_src_compile</c> and <c>gnat_src_install</c> are partitioned in a similar
+ way, allowing easy modifications to be performed at every step. Although,
+ as compilers from both FSF and ACT are becoming more unified,
+ this is rarely necessary in later versions.
</p>
</body>
</section>
+
<section>
<title>SLOTs and virtuals.</title>
+
<body>
<p>
Gentoo has long had support for parallel istallation of different major package
@@ -277,26 +279,23 @@
</table>
<p>
- Thus, the possible examples of "fully qualified" compiler names are:
+ Let's consider two possible examples of fully qualified package names.
</p>
- <table>
- <tr>
- <th>gnat-gcc-4.2.0</th>
- <th>
- <c>gnat-gcc</c> - an FSF version of <c>gnat</c> compiler, released
- along with the <c>4.2.0</c> version of <c>gcc</c>.
- </th>
- </tr>
- <tr>
- <th>gnat-gpl-3.4.6.2006-r1</th>
- <th>
- An AdaCore's (<c>gnat-gpl</c>) version of <c>gnat</c> based on <c>gcc-3.4.6</c>
- backend with the Ada specific code as in <c>gnat-gpl-2006</c>, Gentoo specific
- revision <c>-r1</c>.
- </th>
- </tr>
- </table>
+ <dl>
+ <dt>gnat-gcc-4.2.0</dt>
+ <dd>
+ <c>gnat-gcc</c> - an FSF version of <c>gnat</c> compiler, released
+ along with the <c>4.2.0</c> version of <c>gcc</c>.
+ </dd>
+
+ <dt>gnat-gpl-3.4.6.2006-r1</dt>
+ <dd>
+ An AdaCore's (<c>gnat-gpl</c>) version of <c>gnat</c> based on <c>gcc-3.4.6</c>
+ backend with the Ada specific code as in <c>gnat-gpl-2006</c>, Gentoo specific
+ revision <c>-r1</c>.
+ </dd>
+ </dl>
<p>
As with <c>gcc</c>, the code produced by compiler is only binary compatible
@@ -338,8 +337,8 @@
</p>
<pre caption="gnat install locations">
- <comment># set our install locations</comment>
- PREFIX=${GNATBUILD_PREFIX:-/usr} <comment># not sure we need this hook, but may be..</comment>
+<comment># set our install locations</comment>
+PREFIX=${GNATBUILD_PREFIX:-/usr} <comment># not sure we need this hook, but may be..</comment>
LIBPATH=${PREFIX}/$(get_libdir)/${PN}/${CTARGET}/${SLOT}
LIBEXECPATH=${PREFIX}/libexec/${PN}/${CTARGET}/${SLOT}
INCLUDEPATH=${LIBPATH}/include
--
gentoo-commits@gentoo.org mailing list
^ permalink raw reply [flat|nested] 6+ messages in thread
* [gentoo-commits] gentoo commit in xml/htdocs/proj/en/prog_lang/ada: dev_reference.xml
@ 2007-10-08 20:40 George Shapovalov (george)
0 siblings, 0 replies; 6+ messages in thread
From: George Shapovalov (george) @ 2007-10-08 20:40 UTC (permalink / raw
To: gentoo-commits
george 07/10/08 20:40:57
Modified: dev_reference.xml
Log:
few minor fixes
Revision Changes Path
1.7 xml/htdocs/proj/en/prog_lang/ada/dev_reference.xml
file : http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/en/prog_lang/ada/dev_reference.xml?rev=1.7&view=markup
plain: http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/en/prog_lang/ada/dev_reference.xml?rev=1.7&content-type=text/plain
diff : http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/en/prog_lang/ada/dev_reference.xml?r1=1.6&r2=1.7
Index: dev_reference.xml
===================================================================
RCS file: /var/cvsroot/gentoo/xml/htdocs/proj/en/prog_lang/ada/dev_reference.xml,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- dev_reference.xml 8 Oct 2007 16:13:38 -0000 1.6
+++ dev_reference.xml 8 Oct 2007 20:40:57 -0000 1.7
@@ -175,7 +175,7 @@
<comment># patching gcc sources, following the toolchain</comment>
EPATCH_MULTI_MSG=<const>"Applying Gentoo patches ..."</const> \
epatch <const>"${FILESDIR}"</const>/patches/*.patch
- ...
+ ...
;;
common_prep)
@@ -305,7 +305,7 @@
also be aware of potential differences in the produced <c>ali</c> files.
As such, both <c>${PN}-${SLOT}</c> components are defining the "operational SLOT"
or profile specification. Moreover, a fully qualified profile name will contain
- an additional component - <c>${ARCH</c> to allow for the possibility of crosscompilation.
+ an additional component - <c>${ARCH}</c> to allow for the possibility of crosscompilation.
However the description of this is left to the section dealing with <c>eselect-gnat</c>
internals.
</p>
@@ -346,8 +346,7 @@
DATAPATH=${PREFIX}/share/${PN}-data/${CTARGET}/${SLOT}
<comment># ATTN! the one below should match the path defined in eselect-gnat module</comment>
CONFIG_PATH=<const>"/usr/share/gnat/eselect"</const>
-gnat_config_file=<const>"${D}/${CONFIG_PATH}/${CTARGET}-${PN}-${SLOT}"</const>
- </pre>
+gnat_config_file=<const>"${D}/${CONFIG_PATH}/${CTARGET}-${PN}-${SLOT}"</const> </pre>
<p>Lets go over these locations in more detail.</p>
<table>
@@ -402,8 +401,8 @@
<th><c>CONFIG_PATH</c></th>
<th>
Where data describing these install location is stored for the <c>gnat.eselect</c>
- module. The <c>gnat_config_file</c> points to the file containing the profile-specific
- data.
+ module. The <c>gnat_config_file</c> variable points to the file containing
+ the profile-specific data.
</th>
</tr>
</table>
--
gentoo-commits@gentoo.org mailing list
^ permalink raw reply [flat|nested] 6+ messages in thread
* [gentoo-commits] gentoo commit in xml/htdocs/proj/en/prog_lang/ada: dev_reference.xml
@ 2007-10-25 17:52 George Shapovalov (george)
0 siblings, 0 replies; 6+ messages in thread
From: George Shapovalov (george) @ 2007-10-25 17:52 UTC (permalink / raw
To: gentoo-commits
george 07/10/25 17:52:11
Modified: dev_reference.xml
Log:
some more updates
Revision Changes Path
1.8 xml/htdocs/proj/en/prog_lang/ada/dev_reference.xml
file : http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/en/prog_lang/ada/dev_reference.xml?rev=1.8&view=markup
plain: http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/en/prog_lang/ada/dev_reference.xml?rev=1.8&content-type=text/plain
diff : http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/en/prog_lang/ada/dev_reference.xml?r1=1.7&r2=1.8
Index: dev_reference.xml
===================================================================
RCS file: /var/cvsroot/gentoo/xml/htdocs/proj/en/prog_lang/ada/dev_reference.xml,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- dev_reference.xml 8 Oct 2007 20:40:57 -0000 1.7
+++ dev_reference.xml 25 Oct 2007 17:52:11 -0000 1.8
@@ -414,8 +414,63 @@
<title>eselect-gnat workings</title>
<body>
<p>
- To be completed.
+ <c>eselect-gnat</c> was modelled after the <c>eselect-compiler</c> module, that was
+ supposed to supersede the <c>gcc-config</c> script at the time of development. Of
+ course that got shot down and now we are "stuck" with <c>gnat</c> using the "more
+ modern" tool, while <c>gcc</c> is still handled by legacy <c>gcc-config</c> script.
+ Nonetheless, <c>eselect-gnat</c> works well with the way Ada support is setup in
+ Gentoo, and below I describe its inner workings.
</p>
+
+ <p>
+ Inheriting all the general features of <c>gcc</c>, the run-time behavior of
+ <c>gnat</c> can be extensively regulated by env vars. As such, the approach that was
+ adopted consists of the compiler producing the "specs" file tat contains all the
+ principal locations during its build, and <c>eselect-gnat</c> using this generated
+ file to create an appropriate entry under the <c>/etc/env.d</c>. There are no
+ additional "hidden entries", everything rotates around the way env settings are
+ managed in Gentoo. Thus, <c>eselect gnat set</c>, <c>update</c> and <c>unset</c>
+ actions directly operate on the env entry (re)creating a new or deleting an existing
+ one. This env file has the name of the form <c>${MARKER}${gnat_profile}</c> with
+ <c>MARKER</c> currently set to <c>MARKER="55gnat-"</c> and <c>gnat_profile</c>
+ having a usial form of <c>${ARCH}-${compiler_name}-${SLOT}</c>, such as
+ <c>x86_64-pc-linux-gnu-gnat-gcc-4.2</c> for example. The generation of the original
+ specs file for each compiler is performed by the <c>create_eselect_conf</c> function
+ in the <c>prep-env</c> part of the <c>gnatbuild_src_install</c> function in
+ <c>gnatbuild.eclass</c>. And the specs file location is defined near the op of
+ <c>gnatbuild.eclass</c> as:
+ </p>
+ <pre caption="gnat profile specs location">
+<comment># ATTN! the one below should match the path defined in eselect-gnat module</comment>
+CONFIG_PATH=<const>"/usr/share/gnat/eselect"</const>
+gnat_config_file=<const>"${D}/${CONFIG_PATH}/${CTARGET}-${PN}-${SLOT}"</const> </pre>
+
+ <p>
+ The <c>${CONFIG_PATH}</c> serves as the top directory where all the information
+ necessary for the <c>gnat.eselect</c> is stored. Every gnat installs a single file
+ that has a name/SLOT specific name, thus overwriting the one for older version
+ within the same grouping but avoiding collision with a different compiler or SLOT.
+ Every installed library created a subdir under <c>${CONFIG_PATH}</c> that, in turn,
+ contains library spec files for every gnat profile it was compiled with. More on the
+ libs below, in the corresponding section. The location for <c>${CONFIG_PATH}</c> has
+ been purposedly chosen outside normally config-protected locations, so that spec
+ files are removed when the corresponding version of compiler is unmerged. The same
+ goes for the libs.
+ Therefore, figuring out what variants of gnat are installed is a simple matter of
+ scanning <c>${CONFIG_PATH}</c> for the specs files and then splitting them into the
+ <c>${ARCH}</c>, <c>${compiler_name}</c> and <c>SLOT</c> components. Right now every
+ lib is supposed to create a separate directory for itself and every regular file
+ under <c>${CONFIG_PATH}</c> is expected to be a specs file for some compiler
+ variant.
+ </p>
+ <p>
+ <c>eselect-gnat</c> provides common actions, such as <c>show</c> and <c>list</c> as
+ well as <c>set</c> and <c>update</c>. As all the relevant information for all
+ gnat profiles is concentrated under <c>${CONFIG_PATH</c>, determination of
+ The <c>set</c> accepts the name of the gnat
+ profile to activate as an argument and update simply rege
+ </p>
+
</body>
</section>
</chapter>
@@ -428,7 +483,87 @@
<title>Overview</title>
<body>
<p>
- To be completed.
+ As was described above, in Gentoo we provide multiple SLOTted versions of <c>gnat</c>
+ compilers that users can have installed in parallel. Unlike with many other languages,
+ Ada compilers tend to follows the standard rather tightly. Therefore most, if not all,
+ the common libs are expected to compile cleanly with any compiler, provided it implements
+ the necessary version of Ada standard. Therefore it was decided to provide users with the
+ ability to have libs compiled for all the installed gnat variants and to make eselect
+ to switch to an appropriate lib image when a certain <c>gnat</c> profile is activated.
+ </p>
+ <p>
+ The libs are managed by <c>gnat.eclass</c>, which automates their handling. The principal
+ action happens in the <c>src_compile</c> function. All the installed gnat profiles are
+ geting activated in turn and the lib gets compiled multiple times for every profile.
+ The <c>src_install</c> function then collects the compiled parts and installs them
+ in appropriate locations. The detailed workings of the eclass will be considered
+ below. Here I will just note again, that <c>gnat.eclass</c> is designed to be used
+ with the "common Ada libs" and thus should be used only where appropriate. It makes
+ no sense to use it to build some directly executable application for example.
+ </p>
+ </body>
+ </section>
+
+ <section>
+ <title>Detailed sequence of multi-build.</title>
+ <body>
+ <p>
+ As was already mentioned, the principal "magic" happens in <c>src_compile</c>. Here
+ we have to:
+ </p>
+ <ol>
+ <li>copy the source directory, so that the build does not poison the original,</li>
+ <li>activate the next compiler profile,</li>
+ <li>
+ call the <c>lib_compile</c> callback, which now holds stuff that normally
+ happens in <c>src_compile</c> of a normal ebuild.
+ </li>
+ <li>call the <c>lib_install</c> callback. This function is supposed to be similar to
+ the normal <c>src_install</c> except that it only needs to concern itself with
+ installing the gnat-profile specific stuff. The compiled <c>.a</c> or <c>.so</c>
+ files or config scrits are the most common "ingredients" that are processed by it.
+ </li>
+ </ol>
+ <p>
+ and cycle through these steps untill we go through all the installed <c>gnat</c>
+ compilers. The following code fragment is responsible for doing just this.
+ </p>
+ <pre caption="fragment of gnat_src_compile function">
+gnat_src_compile() {
+ <comment>...</comment>
+ compilers=( $(find_compilers ) )
+ if [[ -n ${compilers[@]} ]] ; then
+ local i
+ for (( i = 0 ; i < ${#compilers[@]} ; i = i + 1 )) ; do
+ <comment># copy sources</comment>
+ mkdir ${DL}
+ cp -dpR "${S}" ${SL}
+ <comment># setup environment</comment>
+ generate_envFile ${compilers[${i}]} ${BuildEnv} && \
+ expand_BuildEnv ${BuildEnv} && \
+ . ${BuildEnv} || die "failed to switch to ${compilers[${i}]}"
+ ...
+ <comment># call compilation callback</comment>
+ cd ${SL}
+ gnat_filter_flags ${compilers[${i}]}
+ lib_compile ${compilers[${i}]} || die "failed compiling for ${compilers[${i}]}"
+
+ <comment># call install callback</comment>
+ cd ${SL}
+ lib_install ${compilers[${i}]} || die "failed installing profile-specific part for ${compiler
+ <comment># move installed and cleanup</comment>
+ mv ${DL} ${DL}-${compilers[${i}]}
+ rm -rf ${SL}
+ done
+ else
+ die "please make sure you have at least one gnat compiler installed!"
+ fi
+} </pre>
+
+
+ <p>
+ Next, the <c>src_install</c> function.
+ Here, we need to
</p>
</body>
</section>
--
gentoo-commits@gentoo.org mailing list
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2007-10-25 17:52 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-10-08 16:13 [gentoo-commits] gentoo commit in xml/htdocs/proj/en/prog_lang/ada: dev_reference.xml George Shapovalov (george)
-- strict thread matches above, loose matches on Subject: below --
2007-10-25 17:52 George Shapovalov (george)
2007-10-08 20:40 George Shapovalov (george)
2007-10-08 15:09 George Shapovalov (george)
2007-10-05 21:54 George Shapovalov (george)
2007-10-05 20:51 George Shapovalov (george)
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox