chicken-hackers
[Top][All Lists]
Advanced

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

Re: [Chicken-hackers] Made a start with CHICKEN 5 proposal


From: Peter Bex
Subject: Re: [Chicken-hackers] Made a start with CHICKEN 5 proposal
Date: Sat, 23 Aug 2014 22:25:32 +0200
User-agent: Mutt/1.4.2.3i

On Sat, Aug 23, 2014 at 11:35:26PM +0400, Oleg Kolosov wrote:
> Thanks for the write up, it looks really promising.
> 
> While at it I would like to propose changing build system to CMake with
> the following considerations:

I'd be willing to take a close look at it, if you can send a patchset.
I don't promise anything, since as you know, we've used CMake before with
disastrous results.  We can't have a build system that's dependent on the
knowledge of one person (I know, our current system doesn't completely
fit that profile either).

>   * Build files (CMakeLists) are cleaner and smaller (IMHO) than the
> current Makefiles.

No doubt.  The current system is an ugly hack.

>   * Much faster build times, especially for larger projects (parallel
> compilation and separate build directories are fully supported).

(How exactly) is this guaranteed to work correctly, dependency-wise?

>   * Supports testing natively - with dependency based rebuilding and
> rerunning by regex match etc. - this can come really handy during
> development. Tests are also portable - no more ugly bash hacks.

Can you go into detail about that?

>   * Native Windows support - works fine with a few small core patches
> (alas due to egg incompatibilities I've not tried on any serious projects).

Great, how does this work?

>   * Native MacOSX - I've not tested it much myself, but got reports that
> it's working.

What do you call "native"?  I'd say our current build is about as native
as it gets.

>   * Can figure out many things about host system automatically - this
> can be leveraged to generate larger chicken.h and simplify files module
> for example. Also we can use it's knowledge to generate library files
> and native executables to simplify command line build tools (csc et al.).
>   * Cross-compiling works.

It would be great if you could supply some instructions (in the README?)
on how to do this, so people can test it.

>   * Can generate project files for popular IDEs.
> 
> With some help from the compiler (namely extracting module dependencies)
> it can be even better. Current implementation is quite hackish in this
> regard.

I think we talked about that, it can't be done in a fully generalised way.

> It would be great to clean up chicken.h and runtime.c somewhat,
> currently they look quite messy to me. Let's move some ifdefed code
> around or break them to few separate files. Maybe drop support for some
> rare platforms - I know, CHICKEN compatibility list looks impressive,
> but I doubt that all of it actually works due to bitrot.

The supported platform list is _fully_ supported.  We tested the
platforms before we made the 4.9.0 release.  What platforms in particular
would you propose we drop?

> The support can
> be added back later to the smaller and modular core. Also let's move all
> inline C from .scm to separate files .c - this will make indexing and
> searching easier and the mess more apparent.

I'd like that, it would also make emacs (paredit) work better.  However,
I don't like the idea to move it into separate C files.  This would result
in way too many files (I think what we have now is pretty much the limit of
what's acceptable, already).

> Is swig stuff in the core really used?

No clue.  AFAIK we don't really support it anymore since CHICKEN 3, but
I could be totally wrong.

> I also would like to see extended C interface for introspecting
> scheme-objects's for example - no concrete proposals - still investigating.

The support we have is comprehensive; core relies on it after all, and
it needs to be able to distinguish everything.  It's just not very
well-documented which may be your main problem.

> ------------
> 
> I'm working on the process-stuff - basically wrapping posix_spawn, it
> also looks quite compatible with the Windows version. But I need to make
> this really fail-safe which turned out to be harder than I imagined.

I don't know whether that's supported on all platforms we support, but
you can give it a try!

Cheers,
Peter
-- 
http://www.more-magic.net



reply via email to

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