Re: There is no consensus on beos yet...

[Bruce Korb <bkorb at sco dot COM>]

Daniel Berlin wrote:
> When fixincludes *does* run (IE after killing the right processes, etc
> necessary to make it go all the way through), it makes more changes than it
> used to, on the same headers. Those changes cause the headers to no longer work
> properly.

*which* headers are broken?  what breaks?  With well over 100 hacks
in the hack definition list, it is not helpful to just know that
one or more are wrong.  Which ones are wrong?  If you don't know
that, then what changes cause the problems?  Then I can figure out
what the cause of the problem.

RE: the processes to kill.  Which processes are you killing?
fixincl subprocesses?  A server shell?  A sed chain?  What?
You keep asserting that it is broken, yet I still do not know
what it is that is not working.

> I already did, it crashes multiple times, hangs, etc.
> It requires killing shell processes off (the right ones) to restart it,
> etc.
> 
> If you think i'm exaggerating, try it.

OK.  Please send me a copy of BeOS :-).  I'm an OS junkie anyway.

> BeOS is not posixy/unix enough to run fixincludes anymore (It used to
> work, and does work with the branch the current released beos compiler is
> based on.

*WHICH* one is that?  The shell script?  (please say, "No" here :)

> However, the diffs from that fixincludes to the current one is
> 800k, which makes it impossible to say "this is the change that caused
> the problems").

Just a diff of the fix*.c files, please.

> The last time i sat and analyzed the problem, I came to
> the conclusion the most likely cause was the way fixincludes was
> comunicating with the processes it was running. However, there is nothing
> inherently wrong with the fixincludes code, it just expects certain
> behavior from piping, etc, that doesn't occur on BeOS.
> Nor is it likely to occur in the future.

What behavior might that be?  As far as I know, it expects to be able
to write on one end of a pipe and have another process read from the
opposite end.  I hope BeOS follows that model  ;-).

> If you want to tell me it's not broken on BeOS, feel free to try
> bootstrapping on a beos system, and see how long it takes you to figure
> out which shell proceses you need to kill to make it keep going.

I am sure it is broken on BeOS.  But I cannot bootstrap it without a copy.
Downloading a gazillion megabytes doesn't work very well over a < 56KB link.