chicken-hackers
[Top][All Lists]
Advanced

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

Re: [Chicken-hackers] [PATCH] Fix #1133


From: Aleksej Saushev
Subject: Re: [Chicken-hackers] [PATCH] Fix #1133
Date: Thu, 03 Jul 2014 11:40:13 +0400
User-agent: Gnus/5.1299999999999999 (Gnus v5.13) Emacs/24.3 (berkeley-unix)

Oleg Kolosov <address@hidden> writes:

> On 06/29/14 13:57, "Jörg F. Wittenberger" wrote:
>> I'm even a fan of not depending on cmake at all. Instead I'd favor a
>> pure Scheme based make process. However I found the plt make macro a
>> little cumbersome to use, and hard to express generation of and
>> dependencies on .import.scm files, I extended it a little and wrote a
>> Scheme-language make process for chicken to test it.
>> 
>> Why? a) reduce dependencies b) reduce mental load for developers c)
>> Scheme makes some things sooo easy, we could have this make look into
>> the module declarations and figure out the dependency hell itself.
>
> There are no problems with generated dependencies in my CMake macros. We
> are using them in our Chicken Scheme based application with few external
> C libraries, 40+ eggs and 50+ internal modules without major problems. I
> even support emitting and using type and inline files automatically. But
> I agree that CMake syntax can be quite ugly for non trivial things.
>
> From the package maintainer point of view idiosyncratic build systems
> are the worst offenders of widespread adoption.

As a packager I can tell you that CMake goes the next in line after SCons,
certainly much higher than autoconf, which makes it rather bad choice
for portable software. In this respect (as in many others) I don't see
how it is any improvement over Make. It is an improvement only in one sense:
it has only one dialect. Once you realize it, you understand that you
could have insisted on using one particular Make dialect which is
exactly what Chicken does.

Besides, generating CMakeLists automatically makes it really suspicious.

> I'm currently experimenting with automatic dependency extraction.
> Unfortunately, apart from make with gcc -M combination, toolchains do
> not expect dependencies jumping into the build graph when the process
> already started. Also this breaks parallel compilation. I have some
> ideas but not yet figured out how to handle this cleanly.

This intervention changes the problem from simple case of planning
that is reduced to topological sort into more general control problem.


-- 
HE CE3OH...




reply via email to

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