[illumos-Discuss] Little question about compilers and a future...

[Garrett D'Amore]

star is way down on the priority list.  I would hope you could
understand why.  (The fact that its a giant webrev, imports a whole new
library interface, and need exceptional handling in our standard cstyle
rules, does not help here.  A low priority easy and low risk delta is
much easier to integrate right now than a low priority webrev with many
thousands of lines of change and requiring special handling.)

If the warnings generated are due to whitespace conflicts, we should try
to fix those ... either by making them no longer conflicting in the
source, or by fixing your cpp.

Of course, you've not posted a webrev, so your work is therefore private
and not useful to the rest of us.  At least not as far as integration in
illumos is concerned.

	- Garrett

On Fri, 2010-09-17 at 21:19 +0200, Joerg Schilling wrote:
> "Garrett D'Amore" <garrett at damore.org> wrote:
> 
> > On Fri, 2010-09-17 at 19:08 +0200, Joerg Schilling wrote:
> 
> > > /usr/lib/cpp is more important than I thought before checking it's relevance.
> > > It is used by rpcgen(1), dtrace(1), aw(1) and as(1) and it is called 1421 times 
> > > when compiling Illumos. Today a full "nightly" succeeded with the OSS 
> > > replacement I wrote.
> >
> >
> > I'm really happy to hear this... I'm glad that you were able to run a
> > full nightly -- this is in fact why I have such requirements -- so we
> > don't get surprises. :-)
> 
> I did never make a public announcement for something being ready, before doing 
> full tests. Last monday, I just mentioned that I reached a state where my cpp 
> works for all rpcgen calls. Life is much easier if you try to avoid 
> missunderstandings....
> 
> 
> > Can you post a webrev somewhere?
> 
> I am currently using a only slightly modified Makefile from AT&T from 1978 and 
> a webrev for a new program does not help anyway.
> 
> I am currently getting 156 warnings like:
> 
> ../../intel/ia32/sys/trap.h: 74: T_AST redefined
> ../../i86pc/genassym/obj32/assym.h: 409: T_AST redefined
> ../../intel/ia32/sys/trap.h: 74: T_AST redefined
> ../../i86pc/genassym/obj32/assym.h: 409: T_AST redefined
> ../../i86pc/genassym/obj64/assym.h: 428: T_AST redefined
> ../../i86pc/genassym/obj64/assym.h: 462: FPU_EN redefined
> ../../i86pc/genassym/obj64/assym.h: 463: FPU_VALID redefined
> ../../i86pc/genassym/obj32/assym.h: 409: T_AST redefined
> /home/schily/Solaris/schily147x/proto/root_i386/usr/include/ia32/sys/trap.h: 74: T_AST redefined
> /home/schily/Solaris/schily147x/proto/root_i386/usr/include/ia32/sys/trap.h: 74: T_AST redefined
> ../../i86pc/genassym/obj64/assym.h: 428: T_AST redefined
> ../../i86pc/genassym/obj32/assym.h: 409: T_AST redefined
> ../../i86pc/genassym/obj64/assym.h: 428: T_AST redefined
> ../../i86pc/genassym/obj32/assym.h: 409: T_AST redefined
> ../../i86pc/genassym/obj64/assym.h: 428: T_AST redefined
> ../../i86pc/genassym/obj32/assym.h: 409: T_AST redefined
> 
> This is not a problem but the expected behavior of a cpp from 1978.
> At that time, redefinitions with different whitespace in the #define line
> have been flagged this way.
> 
> For me, to be able to have a self hosting SchilliX based on redistributable 
> code, this is no problem. For publishing the source, I would like to find a way
> to ignore different whitespace, but the parser is written like people did in 
> the 1970s and so this is not as trivial as the other 10 changes I had to 
> implement in order to be close enough to the Sun cpp.
> 
> P.S.: In general, I tend to finish tasks in chronological order and I am still 
> waiting on a one month old webrev for star integration.
> 
> Jörg
>