tinycc-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Tinycc-devel] Development style


From: David Mertens
Subject: Re: [Tinycc-devel] Development style
Date: Tue, 19 Apr 2016 09:39:12 -0400

Hello Sergey,

This line of yours is symptomatic of a larger problem:

On Mon, Apr 18, 2016 at 11:56 PM, Sergey Korshunoff <address@hidden> wrote:
PS: all new optimizations will break the patch again and again. How
long I must perform
adoptation by myself?

You might pause and ask yourself why *I* have not kept my fork of tcc up-to-date with [mob]. It's not like I want to rely on old, buggy code: I would prefer to keep my code as an offshoot of the latest and greatest tcc.

My fork dates back to 2013. At that time, [mob] compiled on Mac, Linux, and Windows, and "tcc -run" functioned on all three platforms. This functionality is critical for my uses. In the summer of 2014 I decided to update my fork by merging in the latest [mob], only to discover that tcc no longer compiled on Mac! This was something I wanted to address, but I was too busy at the time, so I reverted to my old fork. Since that time, I have been too focused on developing C::Blocks to root through the myriad of commits and figure out when the Mac build was fixed again, if ever.

And herein lies the problem: when you commit code directly to [mob], you run the risk of breaking tcc on platforms where you do not develop or test. This is why you should push your work to a personal mob branch. For more on personal mob branches, see http://repo.or.cz/mob.html

After pushing to a personal mob branch, notify the mailing list. "Check out my latest and greatest work on <ref>. I would really appreciate if folks could test this on <platforms-you-do-no-have>. If all goes well, I'd like to merge this with [mob] in a week. Thanks!"

Then wait for a couple of days for folks to check things out. Expect that if you get any responses, they will likely ask you to do some work. If you really want to merge your code, put the time in and do that work. On the other hand, if you don't get any responses, send a follow-up. Once there is consensus on the mailing list that your code looks good---i.e. multiple people have spoken well of your code---then and only then merge it into mob.

If everybody followed this approach to developing tcc, I would not have nearly as much trouble updating my fork, because we would know which commits work on which platforms.

David

--
 "Debugging is twice as hard as writing the code in the first place.
  Therefore, if you write the code as cleverly as possible, you are,
  by definition, not smart enough to debug it." -- Brian Kernighan

reply via email to

[Prev in Thread] Current Thread [Next in Thread]