On Thu, Aug 18, 2016 at 10:22:24AM -0700, Christopher Manchester wrote: > On Mon, Aug 15, 2016 at 11:51 PM, Mike Hommey <[email protected]> wrote: > > > Hi, > > > > It's almost been 6 months since bug 1250294 landed, initiating the long > > and slow move off autoconf. > > > > Where are we, 6 months later? While there hasn't been constant progress > > in the migration (we've all been busy with other things too), the > > current status is that, pending in-flight bugs, the size of shell and m4 > > scripts is down below 70% of their original size. > > https://plot.ly/~glandium/14/lines-vs-time/ > > > > The python configure script also does more checks than the autoconf > > counterparts we moved. Most notably, we're now verifying that the > > toolchain will actually build for the given --target. > > > > Now, with 30% of the shell and m4 mess moved, and corresponding python > > code written, it's time to sit back and look at what works and what > > doesn't. > > > > Here's my own list of things that I find suboptimal, with suggestions > > when I have some. > > > > - @depends('--disable-foo') and related are confusing. I still think > > that at the sandbox level, it's a good thing that the options are > > treated in consistent manner, ignoring their defaults. But referring > > options by their name incurs some ambiguities along the negatives. > > > > Maybe we should declare all options with their positive name > > (--enable-foo, --with-foo), and set an explicit default of True when > > the option is enabled by default. And make python configure reject > > declarations with the negative name (--disable-foo, --without-foo). > > > > This is probably one of the more confusing points when reading what we have > so far. Related to this, I've always found it a bit disconcerting that > @depends takes any depends function, or a string as an argument, but only > if that string names an option. We could declare options without prefixes > (requiring explicit defaults) and convert these to depends functions > automatically so that option(name='foo', ...) would allow you to write > @depends(foo) immediately thereafter, and never pass a string to @depends.
There are two awkwardnesses with that: - foo is not assigned to from the perspective of the python script. That sure can be made to work in the sandbox, but it does seem like a little too much magic (the kind of magic that doesn't happen when you call a template, btw ; functions defined in a template don't magically end up defined at the global level) - options names have hyphens, and python identifiers can't contain them. Also, declaring options without prefixes leaves you with the question: what is the option supposed to be? --enable-foo, --with-foo, or --foo (we have options in each of those kinds) Now, I don't have data yet, and I will once I'm done with the introspection work I'm doing right now, but the answer to this problem might just be to stop defining options like they are defined today. The original reason for the option() function to act as it does was that there were complicated cases where you have a @depends function that needs to depend on multiple options, and possibly other things. And these cases exist. They've existed early, and there are a number of them. But with progress being made, they may be appearing to be the exception rather than the norm, and the norm is that we end up with more or less pointless @depends functions that do generic things. So depending on what the data says, it might be time to switch option to a decorator. Whether we want to do that completely or not, we can already start doing that with templates. There actually is precedent for it with @deprecated_option. Mike _______________________________________________ dev-builds mailing list [email protected] https://lists.mozilla.org/listinfo/dev-builds
