Progress?

[Steve Poole]

On 13/07/11 22:10, Kelly O'Hair wrote:
> On Jul 13, 2011, at 1:18 PM, Andrew John Hughes wrote:
>
>> On Wed, Jul 13, 2011 at 11:23:19AM -0700, Kelly O'Hair wrote:
>>> On Jul 13, 2011, at 9:43 AM, Andrew John Hughes wrote:
>>>
>>>> On Wed, Jul 13, 2011 at 09:13:05AM -0700, Kelly O'Hair wrote:
>>>>> On Jul 12, 2011, at 2:51 PM, Steve Poole wrote:
>>>>>
>>>>>> Hi Kelly,
>>>>>>
>>>>>> Its seems to have all gone quiet on the infra project.  What's up?
>>>>> Vacations, Paternity leaves, and getting jdk7 out the door distractions. :^(
>>>>>
>>>>> We considered pushing in changes while people were out, but it was decided to wait and
>>>>> have them do the push themselves.
>>>>>
>>>>> I'm also wondering if we should be pulling in the BSD and Mac port logic in at the same time,
>>>>> but that will require setting up BSD and Mac build systems. Just a thought.
>>>>>
>>>> One thing at a time would be better... :-)
>>> But the order might be important.
>>>
>>> When we completely re-write the makefile logic, the BSD/MAC makefile changes will not be of any
>>> value. But if we see these changes first, we can make sure the new makefile logic works for it.
>>>
>> Ah, good point.  I didn't think of that.
>>
>> I don't see a problem as long as they are separate changesets.  I just have nightmares
>> of a single huge unfathomable changeset coming in...
> Yes, we will need to try and organize the changesets in some kind of sane way.
>
>>> The jigsaw/modularity changes to the build system is a bit further off, and it's not clear how this
>>> will impact the build changes we have planned, but the general feeling is that it will be much better
>>> in the new world since we want to try and build the java packages in parallel, with different destinations,
>>> which should be better for modular builds.
>> I'm certainly looking forward to this 'new world'.
>>
>> Is it all done behind the scenes?  Or is there still stuff to work on?
> The issue is that Fredrik, the primary engineer doing the common work, is on leave,
> planned, but unexpectedly early, he should be back soon.
> And he is in Stockholm too, so timezones create a few issues working closely on it.
> I will be in Stockholm the first week of August to try and get something going,
> maybe send out some introduction emails too.
>
> I am a little reluctant to speak for Fredrik on his work, but I had hoped that once he pushed
> his initial changesets into the build-infra/jdk7 area, multiple people could start in on understanding
> it more, maybe help convert any areas of the jdk we miss at first, and definitely test it out and
> see how it works. The build-infra/jdk7 repositories are jcheck-free so no CRs are required as
> we whack away at it to get it right, but I've seen what Fredrik has done as the 'common' logic
> and I want that in place before we throw more people at the problem.
>
> We won't go near jdk8 until we have it all working well, and correct.
> So we await the new 'common' logic, then we can start beating on it and completing
> the assimilation.
>
>> It would be nice if there was some 'TODO' list so others (like me)
>> could get involved if there's still work to be done.  There seems to
>> be little to no collaboration work between Oracle and external
>> contributors at present (I don't mean accepting/reviewing patches, but
>> in working on the same project) and it would be good to see this change.
> Separate from the actual makefile changes, I had hoped we could create some kind of
> jdk image comparison tool that could work on all platforms.
> Something that would accept two jdk image trees (built with different makefiles) and
> compare the files, layout, and file contents, reporting on any differences.
> Besides comparing the more obvious things, like filenames and layouts, it would need to
> rip apart jar and zip files and compare manifests, class files, etc.
> And I was thinking that for binary files maybe decompile the code or do some kind of
> text/data section comparisons so we could verify we have the same image.
>
> Of course it's not jdk specific really, and I haven't seen anything out there that is
> platform independent or capable of doing windows and solaris and linux native
> binaries.
>
> If we had such a tool, we could feel more confident that makefile changes were safe.

Amazingly, I wrote such a tool a few years ago (and it was in Java too)  
I may still have it around somewhere.
Let's suppose I find it  or that we write a new one - where would be put 
the source?   Is there a OpenJDK tools repo?

> If anyone has any ideas on that, I'd like to hear them.
>
> In the past we haven't been very good about doing any kind of inventory check on the
> built images, and the jdk/make/common/Release.gmk file needs to be jettisoned into space. :^(
> Of course, jdk8 will likely have a completely different image structure than jdk7 due to
> the modularity work, but it will still need to be legacy aware somehow. When we get to
> that stage, I'll need help from others, but we are a ways from that yet.
>
> -kto
>
>>
>>> -kto
>>>
>>>>> -kto
>>>>>
>>>>>
>>>>>> (I've just taken ownership of a new laptop with lots of cores and memory and I'd love to use it to build OpenJDK in parallel !)
>>>>>>
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>> Steve
>>>> -- 
>>>> Andrew :)
>>>>
>>>> Free Java Software Engineer
>>>> Red Hat, Inc. (http://www.redhat.com)
>>>>
>>>> Support Free Java!
>>>> Contribute to GNU Classpath and IcedTea
>>>> http://www.gnu.org/software/classpath
>>>> http://icedtea.classpath.org
>>>> PGP Key: F5862A37 (https://keys.indymedia.org/)
>>>> Fingerprint = EA30 D855 D50F 90CD F54D  0698 0713 C3ED F586 2A37
>> -- 
>> Andrew :)
>>
>> Free Java Software Engineer
>> Red Hat, Inc. (http://www.redhat.com)
>>
>> Support Free Java!
>> Contribute to GNU Classpath and IcedTea
>> http://www.gnu.org/software/classpath
>> http://icedtea.classpath.org
>> PGP Key: F5862A37 (https://keys.indymedia.org/)
>> Fingerprint = EA30 D855 D50F 90CD F54D  0698 0713 C3ED F586 2A37