On Tue, Aug 16, 2016 at 03:51:51PM +0900, Mike Hommey wrote:
> Here's my own list of things that I find suboptimal, with suggestions
> when I have some.
> - I'm trying to enforce separation of concerns between generic things,
>   app-specific things and toolkit-specific things. This is something
>   that was essentially completely ignored in autoconf-base configure,
>   and leads to new problems. The main one is that the order in which
>   the python configure files are treated is, for most purposes, app first,
>   then toolkit, then generic. The problem is that e.g. toolchain tests are
>   in the latter, and sometimes we'd need for app or toolkit checks to do
>   toolchain-based checks (concrete example: --enable-valgrind needs to
>   check that valgrind.h can be found)
> 
>   One thing I just thought about while writing the above is that we
>   could have a wrapper around the include() function that, when called
>   for foo.configure, would include all foo.configure files existing in
>   build/moz.configure/, toolkit/, and $build_project/. I haven't thought
>   too much about this one, it may or may not be a workable solution.

Partly related, there's another one:
- there are optional parts of moz.configure that are completely unknown
  when they are not included. This can complicate things in some cases.
  See for example extra_toolchain_flags. IIRC, there are a few other
  similar cases, and I can see other such cases appearing as we move
  more things to python configure.

  By extension, I've been revisiting the idea from bug 1259272 to have a
  tool to do some introspection, and that not everything is visible can
  make it awkward to use such a tool. The worst offender being
  --enable-project/--enable-application.

  I came up with a prototype patch that seems to work and would make
  everything known. The idea is to add a context manager to the sandbox,
  that works as follows:
      with only_when(<some_depends_function>):
          python_configure_stuff()

  We can then rewrite things like depends_when or include_when using
  that context manager. For example, include_when (which is the only
  thing I tested so far) becomes:
      @template
      def include_when(filename, when):
          with only_when(when):
              include(filename)

  I expect it would also allow to remove depends_win from
  windows.configure, for example.

Thoughts?

Mike
_______________________________________________
dev-builds mailing list
dev-builds@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-builds

Reply via email to