Re: [Chicken-hackers] Some questions about CHICKEN 5 eggs and modules

[felix . winkelmann]

Hi, Thomas!

I'll try to address some of your questions.

> - Some eggs install one extension library containing several modules. The new
> CHICKEN module system always tries to load a library named the same as the
> module upon import. Is it no longer possible to separate library loading and
> module import? How can one consume those "compound" libraries now?

To simplify the confusion related to "require-extension", "use", etc.
"import" does now both loading and import in one step. "Compound" libraries
(in the sense of putting more than one module into a single binary) must be
done manually and is not directly supported by the new system. You can
split up your extension into multiple modules and let them load recursively,
by using a wrapper module that imports and reexports bindings, if you need
this.

The underlying machinery is still the same, but in the interest of making
things simpler for the user, the high-level view that can be specified in
egg files provides fewer options. In theory more complex build situations
could be supported, but that would make the egg build system very complex,
as it already has to work across a range of platforms.

>
> - If an (extension ...) form in an .egg file lists modules that have a
> composite name, such as (foo bar), the egg installation process then tries to
> pass the literal "(foo bar)" as a component of the import library name to the
> compiler and it appears in the generated install script. Is this a bug or is 
> it
> intentional? It seems inconsistent with the name mangling using "." between
> module name components that is applied elsewhere.

This is a bug. Compound names should be canonicalized using "." syntax
when they appear in user forms. If you can provide a simple example, we can
try to address this.

>
> - How can I specify compiler flags and native library dependencies specific to
> certain target platforms in an .egg file? As far as I can see, the only way to
> do that is a custom build script, but that has problems of its own.

That is correct. Some mechanism may be provided in the future, I'm not sure
about the details, though. If you can specify "has problems of its own" in
more detail, we can try to address these.

>
> - How can I compile multiple source files, for example one scheme file and
> several C files, into an extension library in an .egg file? As far as I can
> see, the only way to do that is a custom build script, but that has problems 
> of
> its own. In particular it is nearly impossible to do this right in the case of
> static linking, where CHICKEN seems to expect a single object file output 
> (yes,
> ELF object files can be merged, but that's a pain in the rear).

Yes, use a custom build script. I'm working on a way to handle the case of 
separate
..c files that need to be linked. Due to how we support static linking this is
not trivial.

>
> - When I specify a custom build script for an extension library in an .egg
> file, it is used to compile both the extension library and the import
> libraries. Frequently, some special build flags are required for the extension
> library to include / link to native code, but not for the import library.
> Implementing special logic in the build script to differentiate these cases is
> clumsy and error prone. Is there a better way to handle that situation?
>

That is a bug. The import library should not be passed to the custom build.
A patch is currently pending on chicken-hackers.

> - Is there a clean way to install C and Scheme include files somewhere else
> than the default place from an .egg file? It seems to be possible to specify
> absolute target paths, but that is pretty much useless since the prefix of the
> CHICKEN installation is not known at the time the .egg file is written. Also,
> specifying relative *source* paths for include files doesn't even work, if 
> they
> have subdirectory components, because the files get installed in the top level
> target directories but their full relative paths get entered into the 
> .egg-info
> files. An equivalent to custom build scripts doesn't seem to exist for file
> deployment either.

Installation into system paths seems to me somewhat questionable -
files installed for CHICKEN should end in a location specific to that
CHICKEN installation. If you can give a specific example where this
is useful, I'd appreciate it.

A final note: don't expect too much of chicken-install: it is neither a
package system, nor it is a general build system. It addresses the basic
need of installing Scheme libraries. These may use foreign code and
we will try to work on supporting the most common cases.
But not all scenarios can be convered, as you will surely understand,
the different OS- and toolchain-idiosynchrasies are already making
this a serious piece of work. If you have very specialized build- and/or
usage-cases, consider distributing the code not as an egg but as a
normal library using whatever build system you prefer.

Hope this helps.


felix