This seems like it will be helpful. On Feb 17 2014, at 05:55 , Magnus Ihse Bursie <magnus.ihse.bur...@oracle.com> wrote:
> One issue with configure currently is that it is a bit of a "all or nothing" > solution. Either you pass, and then you can build anything in the product, or > you do not pass (since some requirement is missing) and then you can build > nothing -- not even parts of the build that does not really require that > component. For instance, hotspot do not require cups, yet you can not build > just hotspot without having cups installed, since configure won't let you > pass. > > For some of these issues, we have just ignored them, and forced the user to > install unneccessary requirements. For others, we have made more or less > hacky workarounds. For others still, we might skip a requirement if it is not > present, but are not clear about what will be missing. > > Going forward, we will need to handle this in a more structured way. Or said differently, we will have finer grained dependencies. > Here is a proposal, on a very high level, on how we could address these > concerns. > > We start by introducing two new concepts "environment requirements" (could > *really* need a better name!) and "components" (could perhaps need a better > name). perhaps just "dependency" or "requirement" > A "component" is something we will guarantee that it will run, e.g. > "build-jdk", "build-hotspot", "compare-script". If the configure script says > that "build-jdk" is enabled, then we have everything in place to be able to > build the jdk. If it says "compare-script" is enabled, then we can run the > compare script. We might also extend these to include testing, so if > "test-hotspot" is enabled then everything is present to be able to run > hotspot tests. (This is subject of a different debate; let's keep this > possibility in mind but not extend the discussion further on this for now.) > > An "environment requirement" is the vague concept of "something that > configure checks". Typically, it is the presence of some kind of tool, e.g. > "bootjdk", "native-toolchain", "basic-tools", "objcopy", etc. But it could > just as well be some kind of other environmental check, like checking if the > build directory is on a network drive. > > A component will have an associated list of environment requirements. For > instance, build-jdk would require basic-tools, bootjdk and native-toolchain, > etc. If a requirement is not found, configure can handle this in different > ways. If the component was essential, we will fail. If it was non-essential, > we will flag that component as disabled. When I have encountered a component being disabled I was always surprised to learn of it later. I would personally probably always run in "enabled" "forced" mode to avoid surprises. > More specifically, components can be set to either "enabled" (or "forced", > "essential", "required"), "disabled" or "auto" (or "default", "if possible", > or..?). (We need to think about the names a bit...) > * An enabled component must have all its environment requirements fullfilled. > If one or more of these are missing, configure will abort and will not allow > a build. > * A disabled component will not have its requirements checked (unless if that > checking is done since it is needed by another, non-disabled component), and > will be flagged as disabled in the configure output, so you cannot for > instance try to build it using make. > * An "auto" component will have its requirements checked, and will be enabled > if they are present, and disabled otherwise. Either case is fine and will > result in no warnings, but just some kind of information wether it succeeded > or not. This would typically be the default behaviour. > > We will need some suitable set of options to configure to specify which > components should be enabled, disabled or auto. By default, our current > behavior should not change (so build-jdk will need to be enabled, and our > closed extensions would be "auto"). What constitutes a suitable command-line > UI to this functionality is left to be examined. Presumably it will be transitive so if I specify a component "openjdk-images" or "oraclejdk-images" it will check configuration of all components that the named components depend upon. > We would like the configure script to continue to fail-fast as much as > possible, so as soon as we find that we cannot fulfil an environment > requirement of an enabled (essential) component, we will fail. +1 for fast-fail. > Some kind of dependency between components is likely to be needed. For > instance "build-jdk" depends on "build-hotspot", and we have closed-only > extensions that depend on e.g. build-jdk. These dependencies can be satisfied > either by building with make, or with prebuilt packages. We already have > --with-import-hotspot, which should probably be remodeled to fit better into > this scheme. Continuing this path to far leads us to re-implement Maven :-), > so we need to take care to only actually solve the problems we actually need > to. Maven IS too far. ;-) Mike
