[Top][All Lists]

[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.


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. -- or maybe we find a something even better.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]