Re: [Chicken-hackers] C lost -D on chicken-install

[Jörg F . Wittenberger]

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