[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Chicken-hackers] [PATCH] Add missing "C_" prefix to a snprintf call
From: |
Oleg Kolosov |
Subject: |
Re: [Chicken-hackers] [PATCH] Add missing "C_" prefix to a snprintf calls in a tcp module |
Date: |
Mon, 20 Oct 2014 02:34:23 +0400 |
On 19 Oct 2014, at 21:23, John Cowan <address@hidden> wrote:
>
> Peter Bex scripsit:
>
>> 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?
>
> That is what CMake does anyway: it is not a make, but a makefile maker
> like imake or autotools.
>
>> 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 agree. The current Chicken build system is admirable in its simplicity.
> There is no reason why a Windows make file and associated .h file couldn't
> be bundled with Chicken after being generated offline by CMake.
I do not think it’s viable. CMake generates not just Makefile but whole build
system with a lot of system specific information and a bunch of other junk
(like hooks to regenerate itself).
Putting this aside you will also need to change all CHICKEN supporting
utilities (csc and friends) to not assume Unix’ish environment. This will
require a major effort and entail some duplication of work spent on porting
Makefiles.
And considering that the most of Windows projects are using Visual Studio,
integrating them with such Makefile-based CHICKEN will still be a hassle. This
makes the undertaking pointless IMO.
--
Regards, Oleg
Art System