Re: [gentoo-dev] interest assay: eclass for stripping "modern" C[XX]FLAGS

[David Holm]

I wrote an ada eclass which I think I submitted along with the gnat ebuilds. However the
flag-stripping is a straight ripoff from the gcc.eclass function gcc2-flags() and maybe I should
inherit that one instead. It also sets some of the standard variables such as $ADAC, $ADAMAKE
and $ADABIND (these are normally read by autoconf whenever you use it to compile ada code).

Another issue is that when you use gnatmake you cannot just throw in the CFLAGS in a random
order. You have to specify -cargs $(CFLAGS) -largs $(LDFLAGS) and these has to come after the
gnatmake flags and the name of the unit you wish to compile.


On another account. Yesterday I managed for the first time to compile the cvs-version of gnat
which is based on gcc 3.2.3. The version of gnat in gcc cvs is a version taken from
ACTs cvs maybe a month before gcc 3.3 was released. So far I haven't seen a single distribution
which provides gnat snapshots as everyone is either using 3.15p or the gcc version, I will try
to whip up an ebuild of it =). Which also means that it would probably be better to make an
eclass that could detect which version is installed and select the appropriate one.
I will have to read up on eclasses as I'm not very familiar with those yet though and something
similar to gcc-config might be in order as I believe the interest for gnat 3.15p will be big
amongst people doing professional work even after the upcoming version is released.

//David Holm

On Thu, 3 Jul 2003 01:43:38 -0700
George Shapovalov <george@g.o> wrote:

> On Wednesday 02 July 2003 20:25, Mike Frysinger wrote:
> > On Wednesday 02 July 2003 23:11, George Shapovalov wrote:
> > i think we already have a function that does this kind of thing ...
> > see 'strip-flags' ... `man flag-o-matic` if you have a masked version of
> > portage ;)
> Nice try, but this does not cut it ;).
> For one thing that function is gcc version agnostic. For example it will
> permit certain -march combinations which are only supported by >=gcc-3*.
> On the other hand it may be too restricitve in general, by only allowing flags
> listed on some (very small) list.
>
> The function (or alternatively two - three functions containing corresponding
> gcc version in the name) to fit the bill perfectly should only strip
> unsupported flags for the specified version, "correcting" them where
> possible.
> Thus, for example:
> -march=i686  will be permitted, but
> -march=pentium3  will get changed to -march=i686,   and
> -mfpmath=*  will get stripped, etc.
> while keeping other flags intact..
>
> Of course in a very pedantic situation both function could be applied in turn
> yielding converted and (then) stripped flags ..
>
> George
>
>
>
> --
> gentoo-dev@g.o mailing list
>

--
gentoo-dev@g.o mailing list