Re: [Chicken-hackers] [PATCH] Add missing "C_" prefix to a snprintf calls in a tcp module

[Oleg Kolosov]

On 19 Oct 2014, at 18:17, Peter Bex <address@hidden> wrote:
> 
> On Sun, Oct 19, 2014 at 06:02:45PM +0400, Oleg Kolosov wrote:
>> Hello, seeing the patches flowing, I’ve decided to give it a try too, and 
>> push few things related to the MS Visual Studio support.
>> 
>> This one is pretty harmless, just to check the process out.
> 
> Hello Oleg,
> 
> Thanks for the patch, it looks good.  I've pushed it to master and
> chicken-5.  Please note that this is not the best test for the process,
> because we normally require double sign-off on patches, but for trivial
> ones we can push them straight away.

Do you mean that I should sign-off by myself and ask somebody on IRC to review 
and sign-off too? I’ve looked on http://wiki.call-cc.org/contribute - it says 
“send them to the mailing list or fill a ticket”. Perhaps this section should 
be updated.

> 
> See http://wiki.call-cc.org/development-process for more info.
> 
>> I have patched few other things in the core (like cond fixes, nan/inf 
>> handling, removed gcc specifics, added missing ifdefs and so) but you will 
>> not be able to test those without changing the build system to use msvc 
>> compiler (or using CMake). I can extract them and submit here if you are 
>> interested. AFAIKT Unix platforms are not affected.
> 
> I'd hesitate to apply them, because we wouldn't be able to maintain
> them.  We'd need msvc support so we can verify things still work if
> we change things up.  Do you think you could write a Windows Makefile
> which uses the msvc compiler?

I do not think so. This task looks too formidable.

> Alternatively, we maybe we could consider adding your CMake build,
> perhaps as an alternative that co-exists with GMake.  That way we can
> try out how well we can maintain it.  Eventually, the GNU Make support
> could be phased out, if it turns out we're able to maintain it.
> I know that maintaining two build systems is redundant extra work, and
> painful, but switching to CMake altogether is too much of a gamble IMHO.
> 
> I'd like to know what the other hackers think about this.

Well, I’ve tried hard to not break the existing system. It still builds with 
make just fine (but I’ve not tested on anything besides runtests). I intend to 
keep it this way as long as possible to ease merging.

There is another alternative. I maintain our company’s internal fork with CMake 
support and other experimental features and currently in the process of pushing 
it to my github repo, the management is fine with that so far.

In a few weeks we will have point release of our product, and after that, I 
plan to try to rebase it all on chicken-5. If all goes well - we will have a 
public repo with direct commit rights to experiment on as we please without 
spamming the mailing list with the discussions, and you will get some testing 
of the latest development branch on the real world application. Win - win.

-- 
Regards, Oleg
Art System