Some things like the tools package can easily be started right away (almost any CL coder has one, I am sure), while others topics need some discussion because they have great impact on the structure of the wxCL implementation and on what to do next; namely the dissemination strategy, the building of wrappers, and the compilation process interfere to some extend, see the completly revised and sorted-out version of the section "Building Wrappers" of On wxCL: http://www.olivfabric.de/content/on-wxcl.html#007
(It now reflects both the parser-in-CL approach and the SWIG-approach.)
I'd prefer dissemination to look like this:
1) The user installs the platform dependend wxWindows binary.
2) The user installs the CL implementation of his choice.
3) The user downloads exactly one wxCL archive which fits any platform and any CL implementation.
4) S/he fires up hers/his Lisp and loads the wxCL builder which will collect information about the platform, does some low-level performance tests, finalizes the wxCL source code and starts compiling it.
The single archive file must contain the abstract description of the wxWindows classes, and minute knowledge of the foreign function interface of all targeted implementations of Common Lisp.
I think CL compilation of a wxCL distro will not be such a terrifying issue (in comparison to compilation of many CPP apps). For example, the whole Garnet toolkit is compiled on the user's machine and that works almost anytime. If it stucks, usually something is wrong with CLX (a widespread binding of Xlib to CL) which is not part of the Garnet distro but of the individual CL implementations.
Although CPP compilation is more horrid than CL compilation, I expect in most cases compilation of at least one C file is unavoidable during the build of wxCL at the user's machine, because CLISP and CMU-CL, for example, don't provide direct foreign-function interfacing with CPP at all. Both need C functions for interfacing, such that an additional C file needs to be produced which externs CPP function calls with C linking information (see the wxcl-0 archive).
What do you think?
(Joerg)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Here is my suggested agenda for the very next future of the wxCL project:
http://www.olivfabric.de/content/on-wxcl.html#039
Some things like the tools package can easily be started right away (almost any CL coder has one, I am sure), while others topics need some discussion because they have great impact on the structure of the wxCL implementation and on what to do next; namely the dissemination strategy, the building of wrappers, and the compilation process interfere to some extend, see the completly revised and sorted-out version of the section "Building Wrappers" of On wxCL:
http://www.olivfabric.de/content/on-wxcl.html#007
(It now reflects both the parser-in-CL approach and the SWIG-approach.)
I'd prefer dissemination to look like this:
1) The user installs the platform dependend wxWindows binary.
2) The user installs the CL implementation of his choice.
3) The user downloads exactly one wxCL archive which fits any platform and any CL implementation.
4) S/he fires up hers/his Lisp and loads the wxCL builder which will collect information about the platform, does some low-level performance tests, finalizes the wxCL source code and starts compiling it.
The single archive file must contain the abstract description of the wxWindows classes, and minute knowledge of the foreign function interface of all targeted implementations of Common Lisp.
I think CL compilation of a wxCL distro will not be such a terrifying issue (in comparison to compilation of many CPP apps). For example, the whole Garnet toolkit is compiled on the user's machine and that works almost anytime. If it stucks, usually something is wrong with CLX (a widespread binding of Xlib to CL) which is not part of the Garnet distro but of the individual CL implementations.
Although CPP compilation is more horrid than CL compilation, I expect in most cases compilation of at least one C file is unavoidable during the build of wxCL at the user's machine, because CLISP and CMU-CL, for example, don't provide direct foreign-function interfacing with CPP at all. Both need C functions for interfacing, such that an additional C file needs to be produced which externs CPP function calls with C linking information (see the wxcl-0 archive).
What do you think?
(Joerg)