Review Request: 8002028: build-infra: need no-hotspot partial build

[Kelly O'Hair]

On Nov 9, 2012, at 2:53 AM, David Holmes wrote:

>>> 
>>> But with regard to the import, you are forcing the import location to
>>> be a full JDK:
>>> 
>>> + if ! (test -d $HOTSPOT_DIST/lib && test -d $HOTSPOT_DIST/jre/lib); then
>>> + AC_MSG_ERROR([You have to import hotspot from a full jdk image or
>>> hotspot build dist dir!])
>>> 
>>> and I don't understand why. Why can't I import from a JRE or from a
>>> custom build location that doesn't contain lib/jre/... ?
>>> 
>> Ah, I see. The requirements I put in configure matches what Import.gmk
>> is expecting, which I assumed was the layout hotspot will always use in
>> the dist directory. Apart from importing from a JRE, do you know of a
>> case where this wouldn't work? Do we need support for importing from a JRE?
> 
> I'm not aware of any specific need, it just seemed unnecessarily restrictive. But if that is the way things already work that is fine.
> 
> David

The more variations on an import layout, the more likely things will go wrong.
I originally wanted the import layout to be "the JDK" image layout because that was the ONE layout
that made sense to include anything needing to be imported from a pre-built jdk or jre, and it was a well
known layout. So if there is a better layout, so be it, but I would really prefer just one.

Back when hotspot importing was just one file or a few files, life was easier, but importing in
pre-built hotspot files now is very complex and the list is very long.

I don't want to be restrictive, but I also do not want to be responsible for a multitude of ways of
doing the same thing, and insuring that they all work and work well.

I'm the one that historically so many developers ping when things don't work, and it's always
amazing how easy it is for developers, of varying skill levels, to get things wrong.
We really need to avoid unnecessary variations here.

-kto