[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Chicken-hackers] C lost -D on chicken-install
From: |
Jörg F . Wittenberger |
Subject: |
Re: [Chicken-hackers] C lost -D on chicken-install |
Date: |
22 Aug 2018 20:39:52 +0200 |
On Aug 21 2018, Peter Bex wrote:
On Tue, Aug 21, 2018 at 09:22:47AM +0200, address@hidden wrote:
address@hidden wrote:
> There is no bad intent behind this - during the rewrite simply a few
> options were dropped, since they didn't look crucial. If you want it
> back, no problem.
I've been missing it a little bit, but I agree with some of what has
been said and would like to add my 2 cents.
Should the features declared via chicken-install be passed to all
dependencies being built? I think so. Vasilij's example is quite nice to
support this opinion, building hypergiant will bring a lot of other
eggs, and every one of them accept a "gles" feature to build for OpenGL
ES instead of OpenGL.
I ported (not published yet) some of these eggs and I've been missing a
way to do different things depending on whether the gles feature is
defined or not. I think we should add a cond-expand like mecanism in the
egg file format as well, if we add `chicken-install -D` back.
While I'm all for improving things, let's keep an eye on feature creep. We
are only fixing critical bugs here, not adding new features: those can go
into 5.1.
Agreed.
The question whether -D defined features should be propagated to
dependencies easily becomes hairy. As chicken-install is supposed to be
used interactively we would at least need to leave the ultimate decision to
the user. Plus next thing about the default: should already installed
dependencies be re-installed with the new feature installed?
Perhaps for now the easiest way is to blindly pass the -D options onto
csc. If a build script needs to do something special with this info, I'd
suggest using environment variables for now. Alternatively, one could
test-compile a program that uses cond-expand and re-exports it back to
the build script.
It's a bit hacky, but should be enough for these special cases. Using
cond-expand in a build script sounds pretty difficult to do right with
dependencies, because it may result in build and install scripts that
no longer just depend on files for their freshness, but now also differ
depending on what features were selected. This gets hairy very fast!
If this is still considered important, I'd suggest making a ticket for
CHICKEN 5.1 where we can discuss the best approach and weigh our options.
My priorities would be:
1. For chicken 5.0 is vote for:
a. Minimal: To ease the transition process make chicken-install -D emit a
special message suggesting how to proceed. The generic message it costly in
terms of users time figuring out why legacy code ceased to work. May take
years to phase out old code.
b. Better: Simply keep the legacy behavior. Blindly pass -D to csc.
2. Later
a. Hash the options with the code into the key to the egg cache such that
freshness depends on the features too. (If this is easy enough: propagate.)
b. Figure out whether it's worth or not the code complexity to actually
force dependencies to re-install depending on features given (and whether
or not we should blindly re-install all or rather declare the features an
egg is sensitive to under a new keyword in the .egg file and only
re-install things when they are declared to recognize the feature -- which
in turn would prompt the -D feature to better reject features not declared
in the egg -- how was this about feature creep)?
c. Mimic along the lines of the nix package manager.
https://nixos.org/nix/ -- or maybe we find a something even better.
Best
/Jörg
Message not available