Re: [Chicken-users] Re: getopt, getopt_long?

[felix winkelmann]

On Fri, Jul 11, 2008 at 2:42 AM, Ivan Raikov <address@hidden> wrote:
>
>  I agree that if we consider only the essentials needed by
> chicken-setup, is should be possible to simplify egg installation, but
> this is precisely what could be accomplished by isolating the
> semantics in a domain-specific language.
>
>  The current chicken-setup is essentially a Scheme interpreter with
> some macros and procedures for compiling and installing files. There
> is no way, however, to separate the installation by phases, such as
> documentation installation, library installation, etc. You keep
> insisting that such support for installation phases is duplicating
> the functionality of package management tools, but that is not the
> case at all. Installation phases will help support binary packages,
> but would not replace their functionality.
>
>  Instead of manually creating Debian and RPM packages, it would be
> much simpler if the egg format specified what are the make commands
> for compiling, and identified the different components of the egg
> (libraries, executables, tests, examples, documentation). The a Debian
> package creation tool could parse that information and generate the
> corresponding Debian rules and control file.

If you say "the egg format specified", what do you mean exactly? The
.meta file, or a separate entity?

>
>
>  I agree that dpkg and friends would probably do a better job at
> supporting multiple versions of the same egg, etc., so at present I
> don't see the need for incorporating such functionality in
> chicken-setup. But a domain-specific language that allows the
> specification of installation locations, phases, and so on, would
> provide a platform to experiment with such ideas in the future.
>

Ok, I understand. And I do not oppose a higher-level approach to
describing an egg's contents (for example by using a DSL). But
I still would like to simplify it as much as possible (rather provide
the option to use the functionlity of egg setting-up as a library,
and so giving the user full control, instead of trying to write the
perfect package management system). Additionally there is no
way of breaking backwards-compatibility with existing .setup
scripts. The transition to modules will be hard enough and a new
chicken-setup could provide a high-level interface for new eggs
plus a API for old ones.


cheers,
felix