Re: RFR 8054717: SJavac should track changes in the public apis of classpath classes!

bly even > without sjavac. > > -- Jon > > > > On 08/22/2014 08:02 AM, Fredrik Öhrström wrote: > > The path to a super thin client is quite long with a lot of interesting > technical problems (I suppose that is why the royal we has not authorized > RFR:8044131

RFR: 8037085: add support to sjavac to exclude/include directory names instead of only package names.

The previous RFR tried to solve both this simple problem and the larger rewrite of the options but seems to be stalled due to problems with the Windows build. Since it is very inconvenient to have a broken sjavac in jdk9/jdk9, perhaps someone within Oracle could take this simple patch (almost ident

Re: When will JDK 9 builds move to requiring the boot JDK be JDK 8?

ou could build > everything with the new jdk. > Or so I recall.. > > -kto > > On Apr 3, 2014, at 11:54 PM, Fredrik Öhrström wrote: > > >> > >> On Thu, Apr 3, 2014 at 8:53 AM, Joe Darcy wrote: > >>> > >>>> A broader question this issue rai

Re: When will JDK 9 builds move to requiring the boot JDK be JDK 8?

> > On Thu, Apr 3, 2014 at 8:53 AM, Joe Darcy wrote: >> >>> A broader question this issue raises is why are components like corba >>> built using the book JDK rather than the JDK they are a part of? >> >> As Alan said, for historical reasons only. If you wanted to actually compile corba/jaxp/jaxws

Re: RFR: 8035063: Option handling in sjavac needs to be rewritten

cldr/resources \ >> # >> >> When building with sjavac, these get translated to "-e >> java.awt.doc-files.*" which sjavac does not accept, because doc-files are >> not proper package names. Another possible fix would be to filter out non >> valid p

Re: RFR: 8035063: Option handling in sjavac needs to be rewritten

The code by itself looks good. However I think that changing from . to / is a really bad idea. If someone committed a package directory that does not map correctly to the package name, then that is a major problem. You will not find that source through -sourcepath, which means that you just broke

Re: New official README-builds.html

2013/3/15 Andrew Hughes : >> Might want to update configure to check for these libs on linux. >> > > Well that won't work everywhere: > > $ apt-get install libx11-dev libxext-dev libxt-dev libxrender-dev > bash: apt-get: command not found > > so this advice has limited usage anyway. Actually the c

Re: build failure in nashorn with sjavac enabled

Minor glitch in sjavac, it only understands -classpath not -cp. (To be fixed soon.) Temporary fix in nashorn/makefiles/BuildNashorn.gmk change -cp to -classpath in the BUILD_NASGEN setup macro call. //Fredrik 2013/3/1 Maurizio Cimadamore : > Hi, > I was doing experiments with the recently added

Re: Review Request: 8008295: build-infra: Cleanup in Import.gmk

ok 2013/2/15 Erik Joelsson : > Cleaning up in jdk/makefiles/Import.gmk. Removing two copies of the > install-file macro which is already defined in > common/makefiles/MakeBase.gmk. > > http://cr.openjdk.java.net/~erikj/8008295/webrev.jdk.01/ > > /Erik

Re: OpenJDK rebuilding on windows takes a long time

2013/2/15 Ioi Lam : > Is there an option in the makefiles to compile ONLY the .java file that's > changed (assuming I know the changes won't affect other classes)? Yes, configure with --enable-sjavac. Then it will recompile exactly the java files you have touched. And if the public api of the pa

Re: RFR: race with nested repos in hgforest.sh

Fixing get_source.sh problem: We can hardcode pre-creation of the closed repo locations as mkdir -p calls. We can do the openjdk clone first (in parllell) and when that is finished do the closedjdk clone. We can drop parallell clone altogether because it does not give the speedup we are looking fo

Re: RFR: race with nested repos in hgforest.sh

2013-02-04 10:48, Chris Hegarty skrev: There has been some discussion on this with David, but no other takers. Fredrik, am I right that you added the support for parallel clone/update? I believe the changes I have are correct, but maybe you had other ideas about how to solve this issue? -Chr

Re: This simple patch doubles the compile-speed of the hotspot repo on Windows

Issue filed, on its way in: http://cr.openjdk.java.net/~ohrstrom/webrev-8007446-add-MP/ //Fredrik 2013/2/2 Kelly O'Hair : > Great stuff. Have you filed an issue on this? Or shall I? > > > -kto > > On Feb 1, 2013, at 4:58 AM, Fredrik Öhrström wrote: > >> ie. us

This simple patch doubles the compile-speed of the hotspot repo on Windows

ie. use /MP on the cl.exe command line. On the build machine (Windows Server 2007, Visual Studio 2010, 32 HT cores, 64GB ram) configuring with: sh configure --enable-sjavac --with-freetype=/cygdrive/d/tools/freetype-amd64 --with-boot-jdk=/cygdrive/d/java/jdk-7-fcs-bin-b147/ (You need to patch sr

One of THOSE changes has just been pushed....

I.e. 8006872: Stop creating four jars with identical content in the new build system. This changes makefiles in all repoes (but hotspot) and the spec.gmk file. I.e. you have rerun "sh get_source.sh" for the entire build forest and you have to rerun configure. Fortunately, these kind of changes ar

Review Request: 8006872: build-infra: Stop creating 4 identical jars in langtools

Stop creating 4 identical jars in langtools. The jars javac.jar,javap.jar,javah.jar and javadoc.jar contain the same content, except for a minor difference in the manifest that tells where the main class is. This is unnecessary, in particular since javap and javah are not used in the build. A sing

Re: Review Request: 8006663: build-infra: Compare two arbitrary zip/jar files with compare.sh

Ok! 2013/1/22 Erik Joelsson : > Adding functionality to compare.sh to take two zip/jar files as arguments > and just compare those. > > http://cr.openjdk.java.net/~erikj/8006663/webrev.root.01/ > > /Erik

Re: Review Request: 8006658: build-infra: Make MILESTONE behave the same as JDK_BUILD_NUMBER

Ok! 2013/1/22 Erik Joelsson : > In JDK-8001895, MILESTONE and JDK_BUILD_NUMBER were made customizable. But > by mistake, JDK_BUILD_NUMBER could get picked up from the environment while > MILESTONE couldn't. They should behave the same and at this time, listening > to the environment is needed. > >

Re: Review Request: 8004151: build-infra: Generating X11 wrapper offset file is not cross compilable (AWT folks look here!)

;>> >>> (resending to full recepients list) >>> >>> I just hit another issue. I tried using a jdk8 boot-jdk and the order >>> of the output was different in the generated sizes file compared to >>> the one in the repo. Sorting both resulted in a clean

Re: --enable-sjavac not enabled in tl repo yet?

2013/1/18 Weijun Wang : > I just find something interesting. /space on my machine is a symlink to > /home/more/space. If I cd to > /home/more/space/repos/jdk8/tl/build/linux-x86_64-sjavac and configure/make > there, everything is fine. Ah, then sjavac is probably doing canonical or absolute on the

Re: --enable-sjavac not enabled in tl repo yet?

The fix for moving a few source files for the awt bean info classes has not yet propagated into tl, from build. Until then, the tl with --enable-sjavac build will stop somewhere in the jdk when generating sources for awt bean infos. //Fredrik

Re: --enable-sjavac not enabled in tl repo yet?

18 jan 2013 kl. 03:07 skrev Weijun Wang: > Just tried on a latest jdk8/tl clone and > The makefile listed source > /space/repos/jdk8/tl/build/linux-x86_64-sjavac/langtools/gensrc/com/sun/tools/doclint/resources/doclint.java > was not calculated by the smart javac Ok, as the old saying goes, t

Re: Mac problem(?), new build, --with-debug-level=slowdebug

Could you post the hotspot-spec.gmk file? 2013/1/9 David Chase : > Summary: I wanted to debug, I configured thoroughly with slowdebug, but was > not able to debug the result. > > More detailed: > > I configured jdk8tl in common/makefiles, > > sh ../autoconf/configure --with-debug-level=slowdebug

Re: Review request: 8005096: Move a few source files in swing/beaninfo and in a demo.

2013/1/9 Sergey Malenkov : > First, *BeanInfo classes must be packed to dt.jar, not rt.jar. So, it will > be strange to provide sources for nonexistent (by default) classes. > Second, *BeanInfo java files are generated automatically. They are not > well-formatted and well-documented. Ok, I have up

Re: Review request: 8005096: Move a few source files in swing/beaninfo and in a demo.

2012/12/18 Sergey Malenkov : > Looks OK to me. But there are a lot of images in the > make/tools/swing-beans/beaninfo/images folder. Could you please check the > make/javax/swing/beaninfo/SwingBeans.gmk file to ensure that the dt.jar > library will be packed correctly? Yes, I have verified that

Re: Review request: 8005096: Move a few source files in swing/beaninfo and in a demo.

2012/12/16 Kelly O'Hair : > Looks ok to me. But do the makefile comments need to be adjusted? The makefile comments, comment on the fact that Java sources that reside inside make/tools are in fact part of the dt.jar (ie part of the jdk, not just a tool). However this is not that easy to fix, sin

Re: Workaround for partial builds

2012/12/21 Chris Hegarty : > I haven't tried this yet, but this is exactly what I was looking for ( some > way to be partial builds ). The example Erik gave: make jdk-only JDK_FILTER=java/awt Be aware that this workaround is of limited use, since it does not assist in recompiling dependent packag

Re: Review Request: JDK-8004145: build-infra: hgforest.sh cannot be interrupted safely.

2012/11/29 David Chase : > Would it make sense to use "$@" instead of $* in the argument expansion? Yes, and no. It is easy to use "$@" instead of $*, but on the other hand, nothing in the makefiles support spaces in the directory names. On Windows, it sometimes work, since we can rewrite directo

Review request: 8005096: Move a few source files in swing/beaninfo and in a demo.

A few source files, coming from the generated swing BeanInfo files are generated and stored into the wrong source directory, where the path does not correspond to the expected package path. This is unfortunate and makes it impossible for the smart javac wrapper to predict which source files bel

Re: Review Request: 8004151: build-infra: Generating X11 wrapper offset file is not cross compilable (AWT folks look here!)

2012-12-03 17:55, Kelly O'Hair skrev: I notice that some of the $@.tmp stuff has been removed, along with the "$(RM) $@ $@.tmp" commands. I know it's a pain to do this, but I have found it necessary, especially on Windows for some reason. What reason? Can you give an example where it fails on

Re: Review Request: 8004151: build-infra: Generating X11 wrapper offset file is not cross compilable (AWT folks look here!)

2012-11-29 15:54, Fredrik Öhrström skrev: 2012-11-29 15:36, Erik Joelsson skrev: I just submitted a patch to build-infra for the dual generation on all platforms since it breaks comparisons between old and new build. In general, we can't change behavior in new build without also changin

Re: Review Request: JDK-8004145: build-infra: hgforest.sh cannot be interrupted safely.

the old classic, space in directories (/cygdrive/c/Program Files/TortoiseHG/hg.exe). /Erik On 2012-12-03 17:34, Kelly O'Hair wrote: Nicely done. Looks good. You do realize that the "you touched it last" rule may apply here in the future? ;^) -kto On Nov 29, 2012, at 5:17 AM, Fredri

Re: Review Request: 8003414: build-infra: fails on on windows

Looks good. 2012/11/30 Erik Joelsson : > This patch adds an extra check for validating that the windows sdk found by > configure is actually valid. > > http://cr.openjdk.java.net/~erikj/8003414/webrev.01/ > > /Erik

Re: Review Request: 8003819: build-infra: backslashes at end of LIB and INCLUDE in spec.gmk

Looks good. 2012/11/30 Erik Joelsson : > This fixes a problem where the LIB and INCLUDE variables end up with a \ at > the end in spec.gmk. These variables are set in vcvars.bat and configure > extracts them to spec.gmk. Normally they do not end with a backslash, but if > these variables are alrea

Re: Review Request: 8004151: build-infra: Generating X11 wrapper offset file is not cross compilable (AWT folks look here!)

2012-11-29 15:36, Erik Joelsson skrev: I just submitted a patch to build-infra for the dual generation on all platforms since it breaks comparisons between old and new build. In general, we can't change behavior in new build without also changing the old before the old is removed. Removing si

Re: Review Request: 8004151: build-infra: Generating X11 wrapper offset file is not cross compilable (AWT folks look here!)

2012-11-29 15:27, Fredrik Öhrström skrev: The GensrcX11Wrapper.gmk makefile creates a new sizes.32 or sizes.64 by running a generated C program that performs many sizeof calculations on X11 structures. This is cross compileable. That "not" was accidently dropped. Obviously this is

Review Request: 8004151: build-infra: Generating X11 wrapper offset file is not cross compilable (AWT folks look here!)

The GensrcX11Wrapper.gmk makefile creates a new sizes.32 or sizes.64 by running a generated C program that performs many sizeof calculations on X11 structures. This is cross compileable. Fortunately the sizes.32 and sizes.64 offset files are very stable. Thus we can commit them to the source c

Review Request: JDK-8004145: build-infra: hgforest.sh cannot be interrupted safely.

This patch makes sure that pressing ctrl-c when running "sh get_source.sh" actually sends a nice TERM signal to the background mercurial processes so that they can do a nice rollback, if they need to. Really useful, when that clone has stalled, because your network is down, and you want to stop

Re: Review Request: 8004104: build-infra: Minor cleanup

Looks good! 2012/11/28 Erik Joelsson : > Here is a bit of cleanup. > > * A bunch of unnecessary excludes of java-files, since they are in the > platform specific parts of the source anyway. > * An LDFLAGS that should be posix only and was causing a link warning on > windows. > > http://cr.openjdk.

Re: Review Request: 8003482: build-infra: Use correct manifest in security jars

. 12:05 skrev Erik Joelsson: > In this case it's rather to protect against unfortunately timed ctrl-c or > other external interruptions. > > /Erik > > On 2012-11-28 09:26, Fredrik Öhrström wrote: >> Looks ok. However the practice of using $@.tmp is unnecessary if the

Re: Review Request: 8003300: build-infra: fails on solaris when objcopy is not found

Looks good. 2012/11/19 Erik Joelsson : > This is a simple fix for when objcopy is missing. > > http://cr.openjdk.java.net/~erikj/8003300/webrev.root.01/ > > /Erik

Re: Review Request: 8003945: build-infra: problems finding compiler when using --with-dev-kit

I am not really fond of --with-dev-kit, but now its there. However the --sysroot compiler lookup no longer works. Which causes the cross compiles started using --with-builddeps-server to fail.. //Fredrik 2012/11/27 Erik Joelsson : > This fix changes how configure looks for the compiler when -

Re: Review Request: 8004045: build-infra: Error 12 from zip when updating src.zip

Looks good. 2012/11/27 Erik Joelsson : > Small fix for common annoyance when rebuilding images. The zip utility > returns 12 when it has nothing to do. This happens because we run it > multiple times, once for each source root, when updating src.zip, even if > only sources in one of the roots have

Re: Review Request: 8003528: build-infra: Diffs in libjava and hotspot libs on solaris.

Looks good. 2012/11/26 Erik Joelsson : > This fixes a difference between old and new build in libjava.so. It also > adds more exceptions for unavoidable differences in libs from hotspot. > > This also fixes part of 8001460: build-infra: Linker warnings on macosx > > http://cr.openjdk.java.net/~eri

Re: Review Request: 8003844: build-infra: docs target isn't working properly

Looks good! 2012/11/26 Erik Joelsson : > I have fixed the docs target and added support for comparing the generated > docs with the old build. > > http://cr.openjdk.java.net/~erikj/8003844/webrev.01/ > > /Erik

Re: Review Request: 8003477: build-infra: Remove explicit source file listings for libs when possible

Great! 2012/11/26 Erik Joelsson : > This is a bit of a cleanup in CompileNativeLibraries.gmk, removing explicit > listings of source files when they aren't necessary. For some libraries, it > still makes sense to list files to include rather than exclude and those > still have include lists. > > h

Re: Review Request: 8003482: build-infra: Use correct manifest in security jars

Looks ok. However the practice of using $@.tmp is unnecessary if there is no reasonable risk of failure in the recipe. //Fredrik 2012/11/26 Erik Joelsson : > This patch converts 7197071 to the new build-system. > > http://cr.openjdk.java.net/~erikj/8003482/webrev.jdk.01/ > > /Erik

Re: Review Request: 8003317: build-infra: Configure fails when current dir is part of a symlink

Looks good. //Fredrik 14 nov 2012 kl. 15:04 skrev Erik Joelsson: > This is a fix for the logic that prevents configure from creating > configurations in undesired directories. If the path to the source root > contains a symlink, the check got fooled and refused to create a > configuration any

Re: Review Request: 8001875: build-infra: We must be able to force static linking of stdc++

Looks good. //Fredrik 14 nov 2012 kl. 12:38 skrev Erik Joelsson: > http://cr.openjdk.java.net/~erikj/8001875/webrev.root.01/ > > > This patch changes the configure paramater --disable-static-link-stdc++ to > the following: > > --w

Re: Review Request: 8003327: build-infra: "/bin/sh: : cannot execute" on solaris

Looks good. //Fredrik 14 nov 2012 kl. 15:25 skrev Erik Joelsson: > This minimal patch fixes a problem with error messages from /bin/sh on > solaris. > > http://cr.openjdk.java.net/~erikj/8003327/webrev.root.01/ > > /Erik

Re: Review Request: 8001941: build-infra: --disable-precompiled-headers does not seem to work

Looks good. //Fredrik 14 nov 2012 kl. 14:21 skrev Erik Joelsson: > This is a fix for configure parameter --disable-precompiled-headers. It has > now been verified to work. > > http://cr.openjdk.java.net/~erikj/8001941/webrev.root.01/ >

Re: Review Request: 8003274: build-infra: Makefile changes needed for sjavac

12 nov 2012 kl. 19:04 skrev Kelly O'Hair: > Or maybe >if [ "$(words $(shell cat file))" -ne 0 ] ; then > Well, this one is better. I'll switch to this one, eventually. //Fredrik

Re: Review Request: 8003274: build-infra: Makefile changes needed for sjavac

12 nov 2012 kl. 17:45 skrev Kelly O'Hair: > Looks ok. > > xargs used to prune whitespace? That was a new one on me. ;^) After reading through this one: http://stackoverflow.com/questions/369758/how-to-trim-whitespace-from-bash-variable I can only say that it seemed like the easiest solution.

Re: RFR 8003161: Cannot build jdk8/build using the new build system after latest merge.

2012-11-08 11:52, David Holmes skrev: I don't understand this: $$(shell $(MKDIR) -p $$($1_BIN) && $(RM) $$($1_BIN)/_the.$$($1_JARNAME)_include) If you have to create the directory there can't possibly be anything to rm. ??? Two things need to be established before ListPathsSafely is ex

RFR 8003161: Cannot build jdk8/build using the new build system after latest merge.

It seems that some changes (like introduction of cmshalf.c) did not update the new makefiles and caused the OpenJDK only build to fail. http://cr.openjdk.java.net/~ohrstrom/webrev-8003161-root/ http://cr.openjdk.java.net/~ohrstrom/webrev-8003161-jdk/ //Fredrik

Re: Request for Review: Add hotspot support for building with mingw/msys on build-infra (the new build)

2012-10-26 17:02, Kelly O'Hair skrev: I tend to disagree, having multiple words in CC is unconventional, and if we do that, we need to consider the consequences of straying from the typical make convention. But I'd rather not get into what is theoretically wrong or right, it just needs to work,

Re: The future of partial builds

Oookay, long story, this was when we used jdk6 to build jdk7, same kind of problem could occur when using jdk7 to build jdk8: jdk7javac used new features and classes in jdk7, for example: java/util/Objects.java java/util/ConcurrentModificationException.java java/io/File.java java/nio/file/*

Re: The future of partial builds

11 sep 2012 kl. 21:59 skrev Alan Bateman: > With a sjavac config I touched one source file and the incremental build took > 36s so much better. In this case the one class caused 77 classes to be > re-compiled, 10 native files, and 2 shared libraries to be re-linked. On the > other hand, the old

Re: The future of partial builds

Den tisdagen den 11:e september 2012 skrev Alan Bateman: > > So far my experience is that touching native code and re-building is super > fast, it's on par to executing specific make files in the old build (while > wearing the appropriate amulet around one's neck of course). Touching java > classes

Re: Is the "skip boot cycle" trick still needed?

n to describe a set of assorted extra scripts. And, it would fit > more uniformly into the JPRT infrastructure. > > -- Jon > > On 09/10/2012 03:27 PM, Fredrik Öhrström wrote: >> You are right Jon, it is rather easy to do. I just pushed boot_cycle.sh into >> build-infr

Re: Is the "skip boot cycle" trick still needed?

You are right Jon, it is rather easy to do. I just pushed boot_cycle.sh into build-infra. You can do: sh common/bin/boot_cycle.sh and it will create boot_cycle_1 in build, and build the complete product there (including images) then it will create boot_cycle_2 and configure it to use boot_cycl

Re: Need reviewers: more predictable binaries

Looks good. Perhaps we can even remove the "#ifndef THIS_FILE" test in the source files? At some time in the future…. //Fredrik 6 sep 2012 kl. 06:08 skrev Kelly O'Hair: > > Need a reviewer for this change. > > http://cr.openjdk.java.net/~ohair/openjdk8/jdk8-this-file/webrev/ > > It does ch

First webrev for smart javac wrapper

The current build-infra/jdk8 forest can now be configured using --enable-sjavac This causes the build to do proper incremental builds of Java sources (all the other sources are already properly handled when building incrementally) i.e. only the java sources that need to be compiled are actually c

Re: jdk8 makefile changes

The configure script does set a few variables in the spec.gmk file that is used but the hotspot repo. (It does read the spec.gmk file) We did forget about STATIC_CXX though, it should be added to spec.gmk and set appropriately, then the hotspot makefile that looks at it should be adjusted, beca

Re: Review Request: Build-infra update

Nice! Just fix the spelling of "annotaion". //Fredrik 4 jun 2012 kl. 16:15 skrev Erik Joelsson: > I have created a (hopefully temporary) hack to run javah manually for these 5 > classes. This webrev is just against the build-infra repo. Unless anybody > objects to this temporary solution, I w

Re: Review Request: Build-infra update

- jonathan.gibb...@oracle.com skrev: > The rationale for not allowing it is that it has no meaning at either > > the JLS or JVMS level. It would simply be a hint for tools, and hints > > for tools are best done by annotations. > > -- Jon > > On 05/24/2012 12:02

Re: Review Request: Build-infra update

Not by me anyway. In fact, I think that solution is the best one! //Fredrik 2012/5/23 Jonathan Gibbons : > I wanted to be able to declare fields as native, but that was deemed > unacceptable. > > -- Jon > > > On 05/23/2012 10:05 AM, Alan Bateman wrote: >> >> On 23/05/2012 17:50, Kelly O'Hair wrot

Re: Need reviewer - @GenerateNativeHeader

There is no point holding off this push since GenerateNativeHeader annotation and uses of it were already pushed long time ago. These are just the finishing touches to cater for the conversion of the remaining makefiles. If you want another location for the annotation then we can easily search and

Re: Need reviewer - @GenerateNativeHeader

Looks good. Since the annotation is a compile time only annotation, it should not affect any future modularization efforts. Right Alan? //Fredrik 2012/5/23 Kelly O'Hair : > > 7170969: Add @GenerateNativeHeader to classes whose fields need to be > exported for JNI > http://cr.openjdk.java.net/~

Re: Review Request: Build-infra update

In configure.ac: Indententation looks odd where solaris optimizations settings for CC are calculated. Could someone enlighten this configure script with a comment about libCrun? In logger.sh: trap "rm -rf '$RCDIR'" EXIT The $RCDIR is not replaced with the contents of the variable RCDIR since it is

Re: First build-infra push to jdk8 -- try out the new build system!

2012/4/21 Henri Gomez : > new build system is using autoconf ? Yes, please have a look here: http://openjdk.java.net/projects/build-infra/guide.html for detailed instructions. //Fredrik

Re: First build-infra push to jdk8 -- try out the new build system!

; Martijn > > > On 21 April 2012 12:34, Henri Gomez wrote: >> >> New build system has been tested allready on OSX ? >> >> Le 21 avr. 2012 à 09:10, Fredrik Öhrström a écrit : >> >> > For the new build you have to explicitly choose release,fastdebu

Re: First build-infra push to jdk8 -- try out the new build system!

For the new build you have to explicitly choose release,fastdebug or slowdebug. (--with-debug-level=release,fastdebug or slowdebug) So you do not need to turn off fastdebug, it defaults to release. As for the demos and samples. They compile so much faster that there is no point in turning them off

Re: Request for Review: Execute the build logger with the help of a shell if the x permission is not set

Looks good! 2012/4/20 Magnus Ihse Bursie : > In the build-infra hg repo, we allowed execute permission to be set on > files, including common/bin/logger.sh, which is called by the Makefile. > > The official hg repos strip this bit, so when integrating to the build > forest, this was lost, causing

Re: location of -source / -target in new build infrastructure

Yes, a leftover exist in Setup.gmk thanks for spotting that David! the -source 7 -target 7 should be replaced with $(BOOT_JDK_SOURCETARGET) which is setup by configure and stored in the spec.gmk file. That flag is only be used for compiling code that has to be run by the boot jdk. The particular

Re: First build-infra push to jdk8 -- try out the new build system!

- mike.dui...@oracle.com skrev: > Would it be too early to report ‘warning: -jN forced in submake: > disabling jobserver mode.’ results? Not at all, this is a side effect of calling the old makefiles, which do not support multiple jobs. When all the old makefiles are converted, this message

Sv: Request for review: Defs-util.gmk missing in new build system, preventing build

Please remove the reference. //Fredrik - magnus.ihse.bur...@oracle.com skrev: > Background: Building with the new build system fails with > ".../common/shared/Defs-utils.gmk: No such file or directory" in the > build forest, but not in the build-infra forest. > > It turned out that a file

Re: First build-infra push to jdk8 -- try out the new build system!

Have you a correct /tmp setup for cygwin? //Fredrik 2012/4/13 Weijun Wang : > Trying on Windows now. I'm using a VirtualBox VM and the repos are in a > read-only shared folder. So I create a directory in its C: and run configure > there. But when I run make, it shows > > $ make > > >

Re: Review Request: Build-infra M1

2012-03-27 17:21, Michael McMahon skrev: Right. Configure doesn't need to be re-run, but presumably there is some build meta-information linking sources to target libraries etc. Say a new native library libfoo were to be added with associated C (and Java) sources. Where would this get added t

Re: Review Request: Build-infra M1

2012-03-27 16:39, Michael McMahon skrev: A few more things I'd like to understand are: 1) In what circumstances exactly would the configure script have to be re-run? You run configure once to setup a particular build configuration. After it is run, you only need to run make for the build co

Re: Review Request: Build-infra M1

2012-03-26 18:13, Kelly O'Hair skrev: * The "@GenerateNativeHeader" additions seem like they deserve some kind of comment, maybe a short one on the same line, like "No native methods here, but the constants are needed in the supporting JNI code" or something like that? Good idea! * The top

Re: javadoc and API docs

2012-03-26 13:34, Jonathan Gibbons skrev: Right now, in the current build, we use a "hybrid" javadoc to build the API documentation, where "hybrid" means: latest sources, running on bootstrap JDK. Looking to the future, at least for Jigsaw, and now maybe for JSR 308, we may need to run javado

Re: Review Request: Build-infra M1

2012-03-26 12:05, Michael McMahon skrev: > Thanks. It looks like the first of the three options above is most > similar to the verbosity > level of the old build. Is all of this documented anywhere? Well, I have so far really tried to comment in the makefiles. So the "make VERBOSE=" trick is the

Re: Review Request: Build-infra M1

- ahug...@redhat.com skrev: > I know that's the current status quo. It seemed to be being > suggested that the closed rules be removed from the public Makefiles and kept > separately. Maybe I misunderstood. Well, I guess I would like the closed rules be so simple that the default add/overrid

Re: Review Request: Build-infra M1

in increasing order of verbosity make VERBOSE= make VERBOSE=-d make VERBOSE="-d -p" Den fredagen den 23:e mars 2012 skrev Michael McMahon< michael.x.mcma...@oracle.com>: > Is it possible to get a more verbose style of echoing the complete compile/build commands > like the old build ? > > - Micha

Successful cross-compile from 32bit-linux to 64bit-linux

With my latest small pushes to build-infra/jdk8-hotspot-jdk the build-infra forest can successfully cross compile from 32bit-linux to 64bit-linux and vice versa. Some of the final problems were to set HOSTCC,HOST_CC and NIO_CC to be the compiler that compiles code for the build platform. Strip aw

Re: Review Request: Build-infra M1

2012-03-23 00:51, David Holmes skrev: > Not wanting to go too OT here but I see the build-deps server as > something to be used at most per machine rather than per developer. We > have build servers internally that can be used by dozens of developers > and we don't want multiple copies of toolsets

Re: Review Request: Build-infra M1

Yes, of course, I just pushed a fix. Have you changed the class analyzer to output a text file with the mapping of the sources? e.g. java/lang/Object.java jdk.base/java/langObject.java //Fredrik - alan.bate...@oracle.com skrev: > On 21/03/2012 14:07, Erik Joelsson wrote: : > > jdk,

Re: Review Request: Build-infra M1

- ahug...@redhat.com skrev: > What is this builddeps server? Is it something that's worth emulating > elsewhere? A builddeps server is simply an ftp server with tar.gz or zip archives. The builddeps autoconf macros are inspired by the pkg-config macros. Lets look at this extract from configu

Re: Fwd: java -version different on Win vs Cygwin

Interesting. Could it be the 64 bit windows file system virtualization that slow down cygwin so much on 64-bit windows? Are other 32 bit applications as slow? //Fredrik - peter.bru...@oracle.com skrev: > I think I found the answer here: > http://www.curlybrace.com/words/2010/12/17/con

Re: Review Request: Build-infra M1

Until we have done the integration later today. Please just build the openjdk. Thanks! //Fredrik - david.hol...@oracle.com skrev: > On 22/03/2012 6:35 PM, Fredrik Öhrström wrote: > > > > - david.hol...@oracle.com skrev: > >> > >> I tried this today

Re: Review Request: Build-infra M1

- david.hol...@oracle.com skrev: > I couldn't access /home/ohrstrom either :( You can replace my home directory with yours. ;-) > I guess this needs to be taken up internally to see how this > build-deps > stuff is to be setup, configured, and maintained. Something for M2 > perhaps. Yes,

Re: Review Request: Build-infra M1

- david.hol...@oracle.com skrev: > > I tried this today and got a javac error compiling a Java2D demo - as > report to the build-infra list. You are building a closed demo. The fix that written by Alan 2 weeks ago: "Java2Demo breaks build, incompatible method in the same class" has not been

Re: Review Request: Build-infra M1

- david.hol...@oracle.com skrev: > My major concern with the transition here is being able to take > existing knowledge of the build system and be able to figure out where in the > new system certain things are handled. How can I tell if a Makefile is > part of the old build or the new build?

Re: Review Request: Build-infra M1

2012-03-21 16:43, Andrew Hughes skrev: > I haven't tried this out yet, but I'll try and give it a spin in build-infra. > > One thing that did stand out from the patch is that generated files such as > configure are being checked in. For updates to this, is there a plan to > mandate the use of a sp

Re: RFR: 7155585: Fix ifeq errors in makefiles [macosx]

2012-03-21 16:03, Michael McMahon skrev: > Could I get the following change reviewed please for jdk 8? > > It is to fix a number of minor build warnings caused by the macosx changes. > > http://cr.openjdk.java.net/~michaelm/7155585/webrev.1/ > > Thanks > Michael Looks good. //Fredrik

Re: RFR: 7151898: Check for LANG in Mac OS X jdk build sanity check [macosx]

2012-03-15 21:56, Kelly O'Hair skrev: > It is very hard to know the complete impact of building the product in > different locales when > native code is involved. So as much as I would like to guarantee all > selections will work, I would > rather we narrow down the options here to avoid having t

Re: RFR: 7151898: Check for LANG in Mac OS X jdk build sanity check [macosx]

- stuart.ma...@oracle.com skrev: > I don't know, and I don't have the expertise in the build system to > know how other LANG settings would affect the build. Perhaps somebody else on > build-dev knows. Meanwhile, we're patching things up this way, even though it > makes things a bit messier.

Re: Review Request: 7141246 build-infra merge: Introduce new JVM_VARIANT* to control which kind of jvm gets built

2012-03-13 12:00, David Holmes skrev: > That is not really what is happening. KERNEL is gone (going) and MINIMAL > is coming. There are few places where it looks like a rename but that's > a bit of an over-simplificifation. Oh, well, to make it easier for the embedded team, we can wait with the

Re: Review Request: 7141246 build-infra merge: Introduce new JVM_VARIANT* to control which kind of jvm gets built

2012-03-13 00:26, David Holmes skrev: > > You seem to have included the MINIMAL VM changes in here. Those changes > have not been pushed to the mainline and are not yet to be pushed. If > you want to push these build-infra changes you will need to factor out > the MINIMAL VM stuff - else wait.

  1   2   >