My perception of 'make' and 'build' names is similar to what Alexei described. I believe that for most people 'make' is a thing related to making/building process while 'build' is more ambiguous.
Currently we have build system with many 'make/' dirs so it probably bettre to postpone the move to new name to some moment of restructuring the whole build system. I think today it's better to keep consistency. Thanks -Ilya On 10/31/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
I see. I'm familiar with "target" as the place for stuff that's created... Alexei Zakharov wrote: > In other words: I just wanted to say that the big number of java > projects I've been working with was using "build[.<something>]" as a > place for storing generated stuff like .class and .jar files, > generated docs and etc. > > Regards, > > 2006/10/31, Geir Magnusson Jr. <[EMAIL PROTECTED]>: >> >> >> Alexei Zakharov wrote: >> > Take me for example. I will be most likely misleaded with "build" >> > since the majority of projects I've seen in my life were using "build" >> > or "build.<platform>" for storing build artifacts (as Mark said). I >> > agree it is logically to call it "build". But "make" is logical too. >> > "ant" or "ant.scripts" also sound not so bad. Why not to choose the >> > less confusing name? >> >> (I believe you meant "make" or "make.<platform>") >> >> What projects? Java projects? >> >> > >> > With best regards, >> > >> > 2006/10/31, Geir Magnusson Jr. <[EMAIL PROTECTED]>: >> >> Why? I'm really curious about this. We "build" the project, using >> the >> >> "build.xml" file with Ant. >> >> >> >> >> >> Ilya Neverov wrote: >> >> > 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? >> > >> > >> > >
