Re: Mixing Cygnus & Gnat compilers on the same machine

["Marin David Condic" <marin.condic.auntie.spam@pacemicro.com>]

"Scott Ingram" <scott@silver.jhuapl.edu> wrote in message
news:3AE45854.DA5ECDC3@silver.jhuapl.edu...
> There are some weird and wonderful things that can be done with gcc.
> For example
> it is relatively easy to have two or more versions of gcc in the same
> tree.  (Examine
> the "-V" option.)  Unfortunately, this is where the merge of the sources
> becomes
> important...the 2.9x versions of gcc are not Ada aware, so it makes no
> sense to use
> this particular feature.
>
This thread started out with a somewhat different problem - I was trying to
make sure that if I installed Gnat/PC/NT onto my machine that I would not
somehow clobber the Cygnus/gcc/embedded MIPS compiler. This part seems to
have been resolved with an answer of "Yes you can - some minor details to be
resolved along the way..."

The conversation forked to the merger of the Gnat compiler with the gcc
compiler at the Gnu website and so on from there. My observation being that
if the Gnat code merged with the Gnu distribution that it might eventually
meander its way into the Cygnus compiler that targets my embedded machine.

I very much do not want to attempt to monkey around with the Cygnus compiler
and attempt to get the Ada front end integrated with it. Nothing down that
path would constitute "real work" for us here and we tend to have our hands
full making money for the stockholders rather than tinkering with compilers
out of curiosity or a labor of love. It would also be a problem in that we
are going to regularly get updates for the Cygnus compiler and any local
tinkering starts to create headaches for merger. There isn't an Ada mandate
to comply with (or seek to get out from under! :-) or any other "real work"
reason to ask for more problems than we already have, so unless the compiler
comes from Cygnus with Ada already a part of it (as we get C++ as a part of
the C compiler) there is no way I can justify trying to do anything with it
unless it is a trivial amount of work. Everyone here is a C weenie (except
for me) so I just can't see any way of finding a frontal assault into the
organization. ("You want to spend time doing what??? We're doing everything
in C - why change it now? It ain't broke - don't even think of trying to fix
it! We've got a schedule to maintain. You're out of your mind!" :-)


> I think customizations for your platform are unlikely (can't be ruled
> out of course,)
> but building a cross compiler for a supported platform is relatively
> trivial.  As Stephe
> notes, it does require following the directions very carefully.
>
We've got a MIPS processor with some very specialized stuff tightly glued
onto it. We've got our own non-off-the-shelf OS (although it is becoming a
*kind* of Off The Shelf OS... But I digress) and there are some really big
numbers of units utilizing all of the above. I can't rule out that someone
hasn't paid Cygnus to do something to the compiler that adapts it better to
our platform. That said, you can add this to one more reason NOT to muck
about with it.

> Have you built gnat from sources?  I am certainly willing to help if you
> need to.
>
Nope. One day as a hobby or some business venture or brandy-new startup
project, I might find an excuse to do this. As it stands, (and to paraphrase
Marx) "Work is the curse of the tinkering man." The demands of getting the
job out the door may allow for a little newsgroup participation and the
occasional sideline hack job, but building Gnat (or gcc) from sources sounds
like it would be a bit too time consuming to undertake unless I had some
specific purpose in mind. Not having one (and having plenty of other
sideline projects that I *do* have specific purposes in mind for if one day
they stop languishing from neglect & move forward...) I don't want to start
investing time into learning how to rebuild/modify Gnat.


> >
> When they get merged, the source will be available in your distribution
> from
> Cygnus.  Since you are using gcc, I presume that there is no requirement
> for
> a validated compiler to start with.  In that case it simply becomes a
> matter
> of rebuilding the compiler.  (Unless you are also using g++, which is
> problematic
> but not insurmountable.)  Unless there is some requirement for you to
> NOT rebuild
> the compiler...but then we run into a management issue that will have to
> be
> resolved somehow.
>
No I don't need a validated compiler. I was kind of given the impression
that there would be more to it than simply rebuilding the compiler from
sources anyway (otherwise, why wouldn't it then suddenly appear when Cygnus
rebuilt from sources?) I'd certainly believe there would be bugs & testing
needed to get a fully functional product working. (Go look at comments
elsewhere in this thread). I'd easily believe that Cygnus could choose to
make Ada a part of their release and, with some non-Zero level of effort,
get the Ada front end integrated with the rest of their stuff. For me to try
to do that without a mandate would not be a good idea.

>
> I think the issue here is "specific paths."  Technically there is no
> difficulty
> mixing the compilers, or even mixing objects generated by the current
> versions...
> perhaps you could elaborate?
>
By "specific paths" I mean that if Ada gets into the organization via a
specific path, it does so basically unnoticed and unchallenged. I don't mean
by some "technical" path (environment variables, etc). If Ada rides in
piggybacked on top of the Cygnus compiler, nobody is going to say "No, you
can't do that!" If it came in via having to get somebody to purchase it and
get a project to sign up for it, etc., you all of a sudden have to justify
it and are probably going to get told "No, you can't do that!" Its always
easier for someone to say "No" than to say "Yes" - so its better if nobody
has to even see it coming.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/