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

[Ivan Raikov]

Felix,

  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.


  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.

   -Ivan


"felix winkelmann" <address@hidden> writes:

> Allow me a slight rant...
>
> chicken-setup has served us well, but now has mutated into a large
> intricate mess. There has been a rewrite a while ago, but the messiness
> is still there, partly because a tool like chicken-setup has to do so
> many different things (file-system operations, extension handling,
> HTTP download, build invocation, cross-compilation, etc.). I think the
> only solution is to completely dump it and start from scratch. 
>
> If we consider what we
> essentially need (executing .setup scripts in a directory with the
> egg sources), a backwards compatible API for executing the build
> scripts it should be possible to reorganize the installation and
> upgrading of eggs on a user's system in a simpler, better
> maintainable and more transparent way.
>
> I have actually tried to isolate the pure .setup API (hygienic
> branch, module setup-api.scm), but haven't got the time
> or energy to start with such a project (insert the usual *HINT*
> here - if someone would be willing to go for it, he/she could
> rely on my eternal gratefulness).
>
> I think chicken-setup should NOT duplicate functionality that
> modern packaging tools provide. Dpkg and portage will always
> do a better job at that, and it would be more worthwhile to push
> for adoption of eggs into these packaging systems (which, IIRC,
> Ivan already does with debianizing several eggs). But a simple,
> portable, library-only way of fetching a tarball via HTTP, extract,
> build and install it, upgrade it if necessary and listing what's installed
> would make all the extensions available to everybody (and that
> would be enough, IMHO). A bare minimum to have access to all
> those libraries and keep them up to date.