Re: [Chicken-hackers] TinyCLOS 'examples' install path?

[Leonardo Valeri Manera]

On 09/03/2008, Ivan Raikov <address@hidden> wrote:
>
>   Okay, I see what you mean now. I think it might be possible to
>  introduce separate actions or stages in chicken-setup, but I do not
>  want to make any more changes right now, because I need to deal with
>  the side-effects of introducing the -install-prefix option.
>
>   I believe it would be easy to separate the installation of libraries
>  and documentation. The more difficult part would have to do with eggs
>  that use copy-file/move-file to install additional files, and eggs
>  that run make or some other external commands as part of the
>  compilation. One possible scheme would be to introduce the following
>  stages in chicken-setup:
>
>   1. Compilation (via the compile macro, or make)
>   2. Installation of extensions
>   3. Installation of programs
>   4. Installation of scripts
>   5. Installation of documentation
>   6. Files installed with copy-file/move-file
>
>  I think that it would not be very difficult to add options to
>  chicken-setup that only execute a part of the above sequence. But some
>  eggs do things like this:
>
>   (run (csi -qbs atlas-lapack-eggdoc.scm > atlas-lapack.html))
>
>  Logically, this should be part of the compilation process, but of
>  course chicken-setup has no way of telling that. One possible solution
>  would be to prohibit the direct use of the run macro in setup scripts,
>  and instead use a variant of the macro that specifies the stage when
>  it should be executed, e.g.:
>
>   (post-compile (run (csi -qbs atlas-lapack-eggdoc.scm > atlas-lapack.html)))
>
>  "post-compile" here tells chicken-setup that this command should be
>  considered part of the compilation stage, and it should be executed
>  after all invocations of compile or make. So I think what you are
>  proposing is feasible, it just takes a little bit of careful thought,
>  and unfortunately it will require modifying existing setup scripts.

It will, and I do not suggest trying to implement it /now/. It
something that really ought to be done at some point in the future
though.

I really like chicken, and I'd like to see it compete even handedly
with other programming systems even-handedly; from my point of view,
the main issues right now are:

1) Proper SMP support on threaded apps, because these days everything
and its cat has multiple cores.
2) Making distro packager's life easy re. eggs: the changes you put in
trunk already go a /long/ way - though I'm not so sure I like the way
it seems to split the build of certain eggs into multiple
sub-directories of the build path, if only from my own aesthetics pov.
3) A more convenient way of finding out when eggs are updated, again
for distro packagers - there's been some talk of making the egg
post-commit script provide the egg version too... that would help a
lot, I'd think.

I'm not sure how long this 'provide only the latest version' gig can
go on tbh... I get the feeling (from a pure programmer-user pov) that
at some point in the future a solution will have to be found, along
with support for eggs that don't live in the main chicken svn tree.

Us distro packagers can provide versioned egg dependencies ourselves,
but that's something that will need upstream support too, eventually.

In any case, thanks for the hard work you're doing to support my
effort to make chicken more accessible to people.

I hope once everything falls into place and the main gentoo package
tree provides easy access to chicken's eggs, it will generate some
more interest in this wonderful scheme system :)

Cheers,
Leo