+1 IMHO "make" is still much better than "build"
Regards, 2006/10/31, Ilya Neverov <[EMAIL PROTECTED]>:
I would prefer to keep the current name "make" for directories related to build system. For me it looks natural; at least it looks less misleading than "build" :) -Ilya On 10/31/06, Mark Hindess <[EMAIL PROTECTED]> wrote: > > On 30 October 2006 at 18:38, "Geir Magnusson Jr." <[EMAIL PROTECTED]> wrote: > > > > Ilya Neverov wrote: > > > Hello, > > > > > > I want to gather opinions about structure of the "jdktools" component. > > > > > > I'm going to create scripts for moving tools' sources from classlib/ > > > to top-level directory jdktools/ and to prepare patches for build > > > system for building tools from new place. > > > > Cool > > > > > > > > I think the following structure will be appropriate for future > > > evolution of the jdktools: > > > > > > jdktools/trunk/ > > > build.xml > > > make/ > > > > Can we stop persisting this mistake? Please call it "build" :) > > And call 'build' something else like 'target'? > > I'm not actually sure calling it build is a good idea because a number > of common projects use build to contain built artifacts. What is your > objection to 'make'? > > > > doc/ > > > modules/ > > > jre/ # keytool, tool launcher go here > > > build.xml # classes go to jdk/jre/lib/tools.jar > > > make/ > > > src/ > > > jdk/ # javac, jarsigner go here > > > build.xml # classes go to jdk/lib/tools.jar > > > make/ > > > src/ > > > jdwp/ # separate module for large component > > > build.xml > > > make/ > > > src/ > > > > Only comment is that we might want to pull the launcher out to be a > > peer. Otherwise, I like it. > > I'd be a little tempted by that idea too. > > > > > > > Assumptions which look reasonable for jdktool's build subsystem: > > > > > > 1) it works in presence of built classlib (as HDK binaries or as a > > > result of classlib phase of overall build); > > > > yes - think of the same trick we do w/ DRLVM to "reach over" to find it. > > I'd imagine the federated build to then have : > > > > trunk/ > > working_classlib/ > > working_vm/ > > working_jdktools/ > > > > > 2) the 'jre' module is always built before building 'jdk' to provide > > > generic tool launcher and the jre/lib/tools.jar. Probably it will be > > > easy to obtain these items from HDK. > > > > That's one reason why I'd pull the launcher out to it's own module > > > > > > > > I'm rather newbie in the Harmony build system so your thoughts will be > > > very helpful. > > > > Ant and make will be your friends here :) Note that you will have > > native issues (because of the launcher), so please track the way that > > classlib does this wrt platforms to start, and if you find things that > > work better, suggest it. Mark and Ollie are wizards here. > > > > I'd suggest starting out to accommodate (windows,linux) X (x86, x86_64) > > if you grok what I mean, and do it in a way that it will be trivial to > > add other OSs or processor architectures (IPF, for example). > > > This might be a good place to figure out how this should work going > > forward for harmony, rather than experimenting in classlib. > > +1 > > > > > > > Thank you > > > > No, thank you :) > > +1 > > Regards, > Mark. > > > geir > > > > > -Ilya > > > > > > > > > On 10/19/06, Ilya Neverov <[EMAIL PROTECTED]> wrote: > > >> Hi Geir, > > >> > > >> Looks like that creating the "jdktools" source tree and build was > > >> shaded by other tasks. I can help with preparing and checking updates > > >> in the build system. Please let me know what needs to do in this area > > >> (besides svn commits) to complete the task. > > >> > > >> I'm especially interested in completing the move to "jdktools" > > >> structure since there will be a home for the JDWP code, which has beed > > >> voted but still resides in JIRA. Working with SVN will be easier. > > >> > > >> Thanks. > > >> -Ilya > > >> > > >> On 10/4/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: > > >> > yep, that's the plan. And once we have that, we can simplify the > > >> > launcher as well... > > >> > > > >> > Tim Ellison wrote: > > >> > > +1 for creating a jdktools directory. The dependency on the classlib > > >> > > launcher should be relatively light if we go with a simple tools > > >> > > launcher that rewrites the tool invocation into a generic launcher > > >> > > invocation. You may recall the idea was discussed a while ago. > > >> > > > > >> > > So, for example, > > >> > > jdk/bin/javac -source 1.5 -J-Xmx200M FooBar > > >> > > is rewritten to > > >> > > jdk/jre/bin/java -cp jdk/lib/tools.jar;jdk/lib/ecj.jar -Xmx200M > > >> > > org.apache.harmony.tools.javac.Main -source 1.5 FooBar > > >> > > > > >> > > and so on. > > >> > > > > >> > > Regards, > > >> > > Tim > > >> > > > > >> > > Geir Magnusson Jr. wrote: > > >> > >> Geir Magnusson Jr. wrote: > > >> > >>> Now that we have javac, javah, javap (if Tim votes ;) and > > >> keytool, I'd > > >> > >>> like to organize these and add them to the next snapshot. > > >> > >> My bad - the javap isn't being voted on yet. I was thinking of > > >> the jdwp > > >> > >> vote... sorry > > >> > >> > > >> > >>> So I propose adding a new top-level directory called "jdktools" > > >> (and > > >> > >>> rename "tools" to "project_tools") and create a build target that - > > >> > >>> with a dependency on classlib for the launcher - creates the > > >> 'stuff' > > >> > >>> needed to fill into the JDK. > > >> > >>> > > >> > >>> Any comments?
-- Alexei Zakharov, Intel Enterprise Solutions Software Division
