f***@bevuta.com
2018-08-28 18:40:33 UTC
Hi, Thomas!
I'll try to address some of your questions.
"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.
when they appear in user forms. If you can provide a simple example, we can
try to address this.
about the details, though. If you can specify "has problems of its own" in
more detail, we can try to address these.
..c files that need to be linked. Due to how we support static linking this is
not trivial.
A patch is currently pending on chicken-hackers.
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
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.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?
"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 "." syntaxcomposite 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.
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 surecertain 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.
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 separateseveral 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).
..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.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?
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 -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.
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