[openbeos] Re: [haiku-development] Coordinating ports (#2) (was: Re: Distributed Version Control Tools)

  • From: "François Revol" <revol@xxxxxxx>
  • To: openbeos@xxxxxxxxxxxxx
  • Date: Mon, 21 Apr 2008 23:30:17 +0200 CEST

> > I certainly do NOT consider it my job to surf the Web and search 
> > for 
> > outdated ports of software.
> 
> I haven't suggested that you search for outdated patches. I suggest 
> that anyone considering porting software should take a good look 
> around 
> first because this very thing might already exist.

Outdated ports usually are done by not-so outdated people that usually 
already know BeOS and Haiku and the software better and might help 
avoid wasting time understanding why something doesn't work...
But maybe I'm just outdated :D

> 
> > why are there no upstream patches from you?!
> 
> There are no upstream patches for one simple reason: we are using gcc 
> 2.95.3. This is a compiler that doesn't even support C99. That's why 
> patches to get QEMU working require anything that for example puts 
> declarations not at the top of the block (a previous requirement of C 
> code) needs to be edited. I've for example put large numbers of {} 
> into 

Hmm C99 allows that ugliness ???
I always thought that was forbidden in C.
Still there is no reason to do that just because one can.

Btw, it doesn't hurt sending diffs to mailing list even if you know 
they won't get to svn, at least it shows a sign of life, and gets 
archived for others to see (if they consider their job enough to not 
waste time redoing stuff :p)

> some of those files to simply start a new block whenever a variable 
> is 
> declared (because just moving them would be even more time consuming 
> as 
> they usually bring initializations with them that depend on being 
> where 
> they are...). Then QEMU does many tricks with code to get its speed 
> to 
> a reasonable level. Some of those tricks simply do not work under 
> such 
> an ancient compiler like ours (register declarations after 
> functions...) and therefore need some hacks to get things going.

Yes I recall trying to build it and having to remove many targets...

> I would not even consider merging anything like this into a project 
> and 
> I wouldn't suggest putting these patches upstream, because it breaks 
> the design of otherwise (for all paltforms except us) fine code. 
> That's 
> why there are no upstream patches from me.

As I said I try to keep svns buildable at least and regularily send 
diffs for posterity.

> This does not hinder anyone from asking me for a patch or a complete 
> buildable source package though. It just requires that one does a bit 
> of research and realizes that it exists already. I have given out 
> such 
> packages previously, I just want to make sure that the people that 
> are 
> requesting them know why the things look/are hacky in some spots. 

a-1) += ask the publisher of the BeOS bins on bebits btw :)

> That's why I don't just put a patch on my website, but rather email 
> it 
> out with proper explanations and instructions how to get it working. 

You know you can prepend text to diffs, as long as lines don't start 
with - or + they are disregarded by patch, so you can embed 
instructions there...

For things comming from Zeta ports I usually include the custom 
GNUmakefile from the build in the diff, even though it's not directly 
usable, someone caring will notice it contains configure arguments that 
are known to work for zeta.

> This is extra work for me which I invest to keep the quality of the 
> work as high as possible with the constrained resources we have. So I 
> would simply find it nice if others would also invest a bit of time 
> to 
> first take a look around.

I suppose we should get a PR secretary for that kind of stuff :D

> This whole text obviously does not justify that I have attacked you 
> with my first response more than I have intended, for which I'd like 
> to 
> appologize. Let's say I had an "interesting" day today and seeing 
> this 
> going on (the duplicate work thing) and then seeing that you might be 
> right on track to do the same thing with a QEMU port I invested 
> considerable time into already, did tick me off a bit.

You'll get used to it, trust me :D

François.

Other related posts: