Looks good!
Mike
On 2017-02-03 02:21, Magnus Ihse Bursie wrote:
Pass options to serve command in hgforest.sh. Mostly necessary for
--port option.
Original patch was written by Michael Duigou, but it has bit-rotted
since created so I had to adapt it to the current hgforest.sh.
Bug: https://bu
On Sep 24 2014, at 04:59 , pointo1d wrote:
> Hiya Mike ,
> On 24/09/14 00:35, Mike Duigou wrote:
>> Hello all;
>>
>> This is a one line change to the hgforest command to pass the command line
>> options to the serve command. This is mostly useful for pass
Hello all;
This is a one line change to the hgforest command to pass the command line
options to the serve command. This is mostly useful for passing --port option
https://bugs.openjdk.java.net/browse/JDK-8059000
Mike
diff --git a/common/bin/hgforest.sh b/common/bin/hgforest.sh
--- a/common/bi
Looks good.
Do we know if the headless=true is actually needed?
Mike
On Aug 21 2014, at 10:16 , Tim Bell wrote:
> Hi Erik:
>
>> Please review this small patch. In Javadoc.gmk the javadoc command is
>> defined with an explicit mx flag. However, configure is already calculating
>> a suitable
Hello all;
This is a very small fix suggested by bitter_fox which forces English
localization for the 'hg version' message which is parsed by get_source.
webrev: http://cr.openjdk.java.net/~mduigou/JDK-8055772/0/webrev/
jbsbug: https://bugs.openjdk.java.net/browse/JDK-8055772
Reminder: 8055331
Hello all;
This changeset breaks out some the simple and non-controversial changes from
JDK-8042841. The change makes it easier to write scripts around hg incoming,
outgoing, etc. that return exit code 1 for non-error situations. Rather than
returning 1 for all non-zero exit conditions hgforest
There's a lot to review here. This is not a complete review but hopefully
contributes to our review "coverage". I am focusing on the top project in this
set of comments.
- --with-output-sync seems like it should be on by default if available.
Downside? This could also be split out from the jigs
You are correct. The release and fastdebug need to be combined into one clause.
I will fix this. Bash 4.0 doesn't appear to complain about the fallthrough but
better to be compliant.
Mike
On Aug 11 2014, at 15:05 , Kim Barrett wrote:
> On Aug 8, 2014, at 8:23 PM, Mike Duigo
Hello all;
A previous version of this changeset was focused on disabling FORTIFY_SOURCE
only for specific files with optimization disabled. This version entirely
disables FORTIFY_SOURCE for all portions of the build. After additional
problems; incompatibility of FORTIFY_SOURCE with -O0, lack of
The current plan is to just disable FORTIFY_SOURCE entirely in JDK-8050803. The
FORTIFY_SOURCE implementation is just causing too many problems relative to
it's potential benefit.
Mike
On Jul 29 2014, at 06:37 , Andrew Haley wrote:
> In a fastdebug build of JDK9:
>
> Compiling ../generated/
I improved the comments as suggested and fixed a problem with a blank line
being output when OptionOnly is called with empty ADDITIONAL_JAVADOCFLAGS.
webrev: http://cr.openjdk.java.net/~mduigou/JDK-8051010/1/webrev/
Mike
On Jul 17 2014, at 11:28 , Mike Duigou wrote:
>
> On Jul 17 20
On Jul 17 2014, at 11:24 , Alan Bateman wrote:
> On 17/07/2014 18:58, Mike Duigou wrote:
>> Hello all;
>>
>> In Java 8 the core JDK API Javadoc started using several new custom javadoc
>> tags. Other javadoc bundles would like to use the same tags and it's a go
Hello all;
In Java 8 the core JDK API Javadoc started using several new custom javadoc
tags. Other javadoc bundles would like to use the same tags and it's a good
idea to be generating all of the javadoc bundles as consistently as possible.
This changeset provides support for the new custom jav
I will work up a patch tomorrow.
Mike
On Jul 16 2014, at 13:24 , Alan Bateman wrote:
>
> I'm looking to use @apiNote, @implNote and a few other tags in JDK-specific
> APIs. The javadoc for these APIs is generated by make/Javadoc.gmk but I see
> that these -tag options are only used for build
These tags certainly could be added to the other javadoc bundles. Initially I
opted to only add them where essential.
One bit of weirdness you are probably wondering about--why is every tag named?
The reason is that specifying an existing tag with -tag moves it to the end of
the ordering. It's
The makefile changes look fine to me. (The use of OPENJDK as part of the
variable names seems excessive but that's not something your patch adds or
changes)
Mike
On Jul 9 2014, at 23:55 , Petr Pchelko wrote:
> Hello, Build Team.
>
> This is a reminder. Could you please review the build part
hello all;
This is a diverse set of changes that I have been working on for a while to
improve various aspects of the hgforest command.
It includes:
- Various minor cleanups
- Better documentation of options and important shell variables.
- Verbose output mode
- Further refinement of output re
I've updated the webrev with yet a different variant of the extract version
field function.
http://cr.openjdk.java.net/~mduigou/JDK-8048184/1/webrev/
Sorry Dave, I resist all attempts to introduce awk. :-)
Mike
On Jul 8 2014, at 06:44 , Daniel Fuchs wrote:
> Hi,
>
> Thanks Dave,
>
> yes -
at 12:01 , Mike Duigou wrote:
> Hello all;
>
> After pushing JDK-8047925 it was discovered that unofficial development
> builds of Mercurial use a different version string format and get_source.sh
> needs an enhancement to correctly parse this version string.
>
> I have also
Hello all;
After pushing JDK-8047925 it was discovered that unofficial development builds
of Mercurial use a different version string format and get_source.sh needs an
enhancement to correctly parse this version string.
I have also incorporated some cleanup suggested by Dave Pointon, made the
Yes, a reasonable suggestion. I have to update the script to fix the parsing of
the dev build version format, ie. X.Y.Z+ISO8601 and will include this cleanup
with that change.
Mike
On Jun 25 2014, at 02:51 , pointo1d wrote:
> Hiya Mike ,
>
> On 23/06/14 22:50, Mike Duigou wrote:
erwise fine!
Thank you. Corrected.
>
> Cheers,
> Mikael
>
> On Jun 23, 2014, at 14:50, Mike Duigou wrote:
>
>> Hello all;
>>
>> This is the changeset for the enhancement proposed last week. It adds
>> version checks to get_source.sh script. Currently
"command -v foo" looks like a much better option.
Thanks!
Mike
On Jun 24 2014, at 13:22 , Omair Majid wrote:
> * Erik Joelsson [2014-06-04 04:18]:
>> Looks good. Using "which" is a pain.
>
> Have you considered switching away from `which`?
>
> A number of other alternatives, with better beh
Hello all;
This is the changeset for the enhancement proposed last week. It adds version
checks to get_source.sh script. Currently the script will abort if the
Mercurial client is not found or is older than 1.5.0. If Mercurial client is
older than 2.6.3 then a warning will be issued but the scr
With the upgrade of the hg.openjdk.java.net servers very old mercurial clients
can no longer be used (0.9.5) and there have been persistent reports of more
frequent connection failures. The older your mercurial client the more likely
the failures are.
jdk: hg clone http://hg.o
Seems reasonable. I personally have a preference for using the bootjdk for
JT_JAVA but that's mostly a consequence of the bits that I work on--testing a
HashMap change is more difficult when jtreg itself may not be working correctly.
Mike
On Jun 5 2014, at 10:37 , Maurizio Cimadamore
wrote:
I considered making the check a function but opted to do the minimal change
instead. I do agree that it seems like something suitable for a function.
Mike
On Jun 4 2014, at 11:22 , pointo1d wrote:
> Hiya Mike ,
>
> On 03/06/14 23:36, Mike Duigou wrote:
>> Hello all;
>>
Hello all;
This is a small changeset to fix a problem where on some platforms (Solaris and
possibly others) the configure script doesn't properly detect the absence of
autoconf or mercurial because which returns a string for the failure condition.
The recipe used was previously in hgforest.sh f
On Jun 2 2014, at 09:23 , David DeHaven wrote:
> * Why remove MACOSX_VERSION_MIN=@MACOSX_VERSION_MIN@? I believe we still use
> this in some closed makefiles. Or is the idea that we instead will force the
> sdk name to 10.7? If so, then we need to still leave this in until every user
> (RE) h
On May 22 2014, at 09:14 , David DeHaven wrote:
>
> Good point.
>
> I'm also wondering, what if (for whatever reason) MACOSX_SDK_PATH is empty?
>
> That will cause the -isysroot argument to be invalid. I can either make an
> undefined MACOSX_SDK_PATH a hard error (in configure)
Earlier fail
[not a build project Reviewer]
The only change I would make is to put a conditional around the other new
variable in spec.gmk.in.
I wondered if the variable should be MACOS_SDK_PATH since macos.sdk is the name
used in the path.
Mike
On May 20, 2014, at 9:30 PM, David DeHaven wrote:
>
> JB
On May 19 2014, at 18:45 , Vladimir Kozlov wrote:
> Looks fine to me.
>
> We don't use gcc on Solaris. How you tested solaris/makefiles/gcc.make
> changes?
I have not been able to test the Solaris changes. It is my understanding that
the gcc on solaris makefiles have not been tested in some
unexpected flag changes.
http://cr.openjdk.java.net/~mduigou/JDK-8032045/7/webrev/
Mike
On May 8 2014, at 12:13 , Mike Duigou wrote:
> Ping. Still needing reviewers on this issue.
>
> I plan to push this change through the hotspot-rt repo.
>
> Mike
>
> On May 3 2014, at 20:
[not a review]
On May 16 2014, at 17:45 , Omair Majid wrote:
> Hi,
>
> Webrevs are at:
> http://cr.openjdk.java.net/~omajid/webrevs/system-libjpeg/00
> http://cr.openjdk.java.net/~omajid/webrevs/system-libjpeg/00.jdk
>
> This patch modifies OpenJDK to allow building and running using the
> sys
Hello all;
A very small but high priority changeset. A stray ")" snuck in and was missed
by both me and reviewers of JDK-8042810.
http://cr.openjdk.java.net/~mduigou/JDK-8043182/0/webrev/
Wouldn't it be cool if there was a tool which validated the syntax of your
source code long before it need
d bashisms such as referencing
undefined variables, previously failing to report result code of root repo and
use of $() in "serve" command.
http://cr.openjdk.java.net/~mduigou/JDK-8042810/1/webrev/
Mike
On May 8 2014, at 19:19 , Mike Duigou wrote:
> Hello all;
>
> This is
On May 9 2014, at 01:54 , pointo1d wrote:
> Hi Mike ,
>
> On 09/05/14 08:25, Mike Duigou wrote:
>> On May 8 2014, at 22:35 , Chris Hegarty wrote:
>>
>>> Looks fine to me Mike.
>>>
>>> Trivially while you are there (not related to your changes)
Looks good to me.
A very useful addition that I plan to port to the jdk repo.
Mike
On May 12 2014, at 11:16 , Dan Smith wrote:
> A patch to enhance langtools/test/Makefile is inline, below.
>
> This addresses JDK-8042882, adding a variable to control verbosity. I've
> also slipped in a fi
On May 9 2014, at 03:54 , pointo1d wrote:
> Hi Mike ,
>
> On 09/05/14 03:19, Mike Duigou wrote:
>> Hello all;
>>
>> This issue is a follow-on bug fix to JDK-8041151 (Improve hgforest.sh
>> concurrency). That changeset introduced use of fifos for monito
ng less-than but no
less-than-or-equal-to operator. I can fix this easily and will do so before
pushing. It's simply a matter of reducing at_a_time to 0. This will look odd
but solve the problem.
>
> -Chris
>
>> On 9 May 2014, at 03:19, Mike Duigou wrote:
>>
>>
Hello all;
This issue is a follow-on bug fix to JDK-8041151 (Improve hgforest.sh
concurrency). That changeset introduced use of fifos for monitoring sub-shell
completion and included an alternative implementation for configurations which
did not properly support fifos. This changeset detects an
Ping. Still needing reviewers on this issue.
I plan to push this change through the hotspot-rt repo.
Mike
On May 3 2014, at 20:24 , Mike Duigou wrote:
> Hello;
>
> Finally getting back to this issue I have done some cleanup and adjusted the
> hotspot gcc.make files to use VA
Hello all;
This is a small enhancement to hgforest.sh cloning which will include cloning
the extra repos if they exist.
https://bugs.openjdk.java.net/browse/JDK-8042417
http://cr.openjdk.java.net/~mduigou/JDK-8042417/0/webrev/
This feature was requested by a user who has been doing file copies
Mike
On Mar 11 2014, at 05:47 , Magnus Ihse Bursie
wrote:
> On 2014-03-11 00:49, Mike Duigou wrote:
>> I have updated the patch to respond to Magnus's feedback and to accommodate
>> intervening changes to the configure and hotspot make files.
>>
>> http
Not a problem.
Mike
>
> Thanks,
> /Staffan
>
> On 19 apr 2014, at 01:21, Mike Duigou wrote:
>
>> Hello all;
>>
>> This is an improvement to hgforest to increase it's concurrency behaviour.
>> Currently hgforest.sh limits the rate at which it start
Nice to see this improved.
Mike
On Apr 22 2014, at 06:29 , Erik Joelsson wrote:
> (reposting with correct subject)
>
> On 2014-04-22 15:28, Erik Joelsson wrote:
>> I recently had to work with make/Javadoc.gmk and felt that it needed some
>> attention. This patch makes it behave correctly for
introduced, but I will add that if I find a need for it.
>
> /Erik
>
> On 2014-04-19 20:54, Mike Duigou wrote:
>> Hello all;
>>
>> In some cases the results of find operations need to be more specific.
>> Adding a filter capability to the find/caching stage
Hello all;
In some cases the results of find operations need to be more specific. Adding a
filter capability to the find/caching stage would reduce the overhead of some
requests. This changeset adds an optional second parameter allowing a find
expression to provide additional filtering of find
Hello all;
This is a very simple patch which causes the already calculated MEMORY_SIZE
variable to be emitted into the spec.gmk where it can be used by make scripts.
Generally this will be to provide a different calculation of the number of
concurrent jobs.
JBSBUG: https://bugs.openjdk.java.ne
Hello all;
This is an improvement to hgforest to increase it's concurrency behaviour.
Currently hgforest.sh limits the rate at which it starts new sub-processes
because it wants to limit the number of concurrent tasks. The naive approach it
takes can cause unnecessary delays. For sequences of o
On Apr 17 2014, at 03:20 , Dave Pointon wrote:
> On Tue, 2014-04-15 at 13:30 -0700, Mike Duigou wrote:
>> [fix missing title]
>>
>> On Apr 15 2014, at 13:30 , Mike Duigou wrote:
>>
>>> Hello all;
>>>
>>> The recent change to fixpath in
When this is changeset is pushed please send message out to jdk9-dev to inform
everyone that the change has been made. Will you be pushing it to jdk9/dev or
jdk9/build?
Mike
On Apr 16 2014, at 03:01 , Erik Joelsson wrote:
> There are now changes in jdk9 which prohibit the use of jdk7 as boot
er the commas, if you are fixing other formatting
> issues?
>
> /Magnus
>
> On 15 apr 2014, at 22:30, Mike Duigou wrote:
>
>> [fix missing title]
>>
>> On Apr 15 2014, at 13:30 , Mike Duigou wrote:
>>
>>> Hello all;
>>>
>>&
Looks good!
Mike
On Apr 16 2014, at 01:07 , Erik Joelsson wrote:
>
> On 2014-04-16 09:14, Erik Joelsson wrote:
>>
>> On 2014-04-15 18:41, Mike Duigou wrote:
>>> I am curious why you didn't make it conditional based upon DEBUG_LEVEL like
>>> jdk and
[fix missing title]
On Apr 15 2014, at 13:30 , Mike Duigou wrote:
> Hello all;
>
> The recent change to fixpath in JDK-8039411
> (https://bugs.openjdk.java.net/browse/JDK-8039411)
> (http://hg.openjdk.java.net/jdk9/dev/rev/45183b39d300) introduced a
> regression for zer
Hello all;
The recent change to fixpath in JDK-8039411
(https://bugs.openjdk.java.net/browse/JDK-8039411)
(http://hg.openjdk.java.net/jdk9/dev/rev/45183b39d300) introduced a regression
for zero length arguments.
This changes forces quoting of zero length arguments. It also contains fixes to
a
I am curious why you didn't make it conditional based upon DEBUG_LEVEL like jdk
and corba? It would be difficult/annoying to turn it on if needed.
The name "GENERATE_NEWBYTECODE_DEBUG" is also confusing since the bytecode is
not tuned for debugging.
Mike
On Apr 15 2014, at 09:03 , Tim Bell wr
There was some suggestion in the past that a JRE would not include symbols in
it's RT.jar but a JDK would. For packaging reasons this apparently never
happened though it has been often requested.
Mike
On Apr 14 2014, at 01:41 , Erik Joelsson wrote:
> Interesting question. I did a comparison o
You might wish instead to do local clones of the first repo.
hg clone http://hg.openjdk.java.net/jdk9/dev first
cd first
sh get_source.sh (with possibly some "magic" url)
cd ..
hg clone first second
cd second
sh get_source.sh ../first
If you need to move repos between local machines or VMs you ca
On Apr 11 2014, at 12:06 , Chris Hegarty wrote:
> On 11 Apr 2014, at 18:55, Mike Duigou wrote:
>
>> Have you looked at using rebase?
>
> I have not, in any detail.
>
>> I've been using
>>
>> sh common/bin/hgforest.sh pull
>> sh common/b
Have you looked at using rebase? I've been using
sh common/bin/hgforest.sh pull
sh common/bin/hgforest.sh rebase
sh common/bin/hgforest.sh update
rather than get_source.sh as it allows me to skip the qpop/qpush steps.
Mike
On Apr 11 2014, at 07:58 , Chris Hegarty wrote:
> Anyone using MQ for
On Apr 8 2014, at 23:26 , Erik Joelsson wrote:
> Indentation look weird around line 460 and 470 (tab vs space?), otherwise
> it's ok to me.
Corrected before push. Some text editor I was using was allowing tabs to sneak
in.
Mike
>
> /Erik
>
> On 2014-04-08 21:31,
Looks good to me and useful. (Other than that I had hoped to claim "-s" for a
future change I planned ;-) (no worries, I will use "-r" for that))
Mike
On Apr 10 2014, at 08:54 , Chris Hegarty wrote:
> Sometimes I get a little confused/nervous when trying to push/status/in using
> the hgfores
On Apr 8 2014, at 03:43 , Dave Pointon wrote:
> On Mon, 2014-04-07 at 14:53 -0700, Mike Duigou wrote:
>> Hello all;
>>
>> http://cr.openjdk.java.net/~mduigou/JDK-8039411/0/webrev/
>>
>> Mike
>
> Hiya Mike ,
>
> My, you _were_ busy :-)
>
>
t looks good in general. If you are able
>> to test it on mingw/msys I think that would be good since it's a pretty big
>> change.
>>
>> /Erik
>>
>> On 2014-04-07 23:53, Mike Duigou wrote:
>>> Hello all;
>>>
>>> Current
Hello all;
Currently the fixpath utility used in windows builds expects that the first
parameter it is passed will be the path of the executable. In some cases it's
desirable to define environment variables which will apply during the execution
of that executable. This change adds support for d
On Apr 3 2014, at 08:23 , Wang Weijun wrote:
> It looks like the problem is at
>
> common/bin/hgforest.sh:
> 222 pull_newrepo="`echo ${pull_base}/${i} | sed -e
> 's@\([^:]/\)//*@\1@g'`"
>
> It tries to substitute all repeated slashes into one unless it's after a
> colon.
>
> *Mi
The general plan had been to wait until Java 8 was final before switching from
JDK 7 to JDK 8. We planned switch internal Oracle build systems to JDK 8 after
the April 15th CPU release. However, since there seems to already be a mix of
JDK 7 and JDK 8 in use it is probably appropriate to switch
u/JDK-8038435/1/webrev/
Mike
On Mar 26 2014, at 15:15 , Mike Duigou wrote:
>
> On Mar 26 2014, at 14:52 , David Katleman wrote:
>
>> Hi Mike,
>>
>> A few minor comments, overall looks good.
>>
>> On 3/26/2014 2:11 PM, Mike Duigou wrote:
>>> Hell
On Mar 26 2014, at 14:52 , David Katleman wrote:
> Hi Mike,
>
> A few minor comments, overall looks good.
>
> On 3/26/2014 2:11 PM, Mike Duigou wrote:
>> Hello all;
>>
>> I introduced bug in JDK-8030681 which prevents non-clone commands from
>> recei
Hello all;
I introduced bug in JDK-8030681 which prevents non-clone commands from
receiving parameters.
I also slightly cleaned up checking for what is an acceptable root repo as I
had encountered this in a problem with a local clone and reverted prior change
which made the script a bash scrip
On Mar 20 2014, at 01:53 , Magnus Ihse Bursie
wrote:
> On 2014-03-20 02:51, Mike Duigou wrote:
>> Hello all;
>>
>> This is a patch which adds support for the "serve" command to hgforest as
>> well as providing --quiet and --verbose options.
>>
>
Hello all;
This is a patch which adds support for the "serve" command to hgforest as well
as providing --quiet and --verbose options.
The serve command is particularly useful for sharing repos with virtual
machines used for building/testing. Using "serve" is generally faster and has
fewer prob
Is your bootjdk a 32 bit VM? Brad Wetmore had similar issues last week. The
problem in his case was that the 32 bit VM couldn't get a large enough heap.
Switching to a 64 bit boot jdk resolved the issue for him.
Mike
On Mar 12 2014, at 14:45 , Phil Race wrote:
> I'm on Windows 7 64 bit and I
to be pushed.
Mike
On Feb 20 2014, at 15:43 , Mike Duigou wrote:
> Hello all;
>
> This issue is a followon to JDK-8030350
> (https://bugs.openjdk.java.net/browse/JDK-8030350) which enhanced the
> compiler warnings used for compiling native code. The proposed changes
> princ
On Feb 24 2014, at 06:09 , Magnus Ihse Bursie
wrote:
> Mike,
>
> I have only looked at toolchain.m4.
>
> First of all, I like the $C_O_FLAG_DEBUG logic.
>
> Some questions/comments:
> * Have you tested the -qnoopt option on xlc?
I copied it from the hotspot makefiles but have not tested it p
On Mar 1 2014, at 06:07 , Yasumasa Suenaga wrote:
> Hi David,
>
>> 1. Generating debug symbols in the binaries (via gcc -g or whatever)
>> 2. Generating debuginfo files (zipped or not) (FDS)
>> 3. Stripping debug symbols from the binaries (strip-policy)
>>
>> It may be that we don't have clean
Hello all;
Currently the parameter passed to configure --with-bootjdk-jvmargs is ignored.
This changeset improves(*) the handling of the args.
http://cr.openjdk.java.net/~mduigou/JDK-8036079/0/webrev/
I also cleaned up the defaults slightly to better capture the intent of the
tests. ie. check
On Feb 24 2014, at 06:09 , Magnus Ihse Bursie
wrote:
> On 2014-02-21 00:43, Mike Duigou wrote:
>> Hello all;
>>
>> This issue is a followon to JDK-8030350
>> (https://bugs.openjdk.java.net/browse/JDK-8030350) which enhanced the
>> compiler warnings us
Looks good to me.
Mike
On Feb 21 2014, at 05:31 , Magnus Ihse Bursie
wrote:
> This bug covers several small improvements in how our configure eco-system
> integrates with autoconf. More specifically:
>
> * Fix so config.status --recheck works.
> * Let the top-level configure script determin
I've tried John's suggestion and it helps but is not enough. I believe I would
have to trap the outer make invocation as well. Unfortunately wrapping make in
a script just to be able to to use ctrl-\ is probably not worth it.
I'm instead using jstack though it can be harder to get timing right.
This seems like it will be helpful.
On Feb 17 2014, at 05:55 , Magnus Ihse Bursie
wrote:
> One issue with configure currently is that it is a bit of a "all or nothing"
> solution. Either you pass, and then you can build anything in the product, or
> you do not pass (since some requirement is
Hello all;
This is a small cleanup patch with provides better summary help output for
reconfigure and dry-run configurations.
http://cr.openjdk.java.net/~mduigou/JDK-8034979/0/webrev/
I do note that even though no configuration is created/updated in "--no-create"
mode the output directory is c
On Feb 12 2014, at 09:31 , Henry Jen wrote:
> On 02/12/2014 07:11 AM, Magnus Ihse Bursie wrote:
>> 12 feb 2014 kl. 14:55 skrev Erik Joelsson :
>>
>>> First I was disappointed to lose the configure-arguments file, which I
>>> sometimes look in to see how configure was run, but I can just as wel
Hello all;
This is a final update to the previously reviewed changeset. I had to make one
slight change in hotspot/src/os/bsd/vm/os_bsd.cpp to accommodate a problem
which appeared since this process began.
http://cr.openjdk.java.net/~mduigou/JDK-8030350/5/webrev/
This change will be integrated
Part of the issue seems to be that the meaning of -Wno-unused seems to have
changed and/or become ineffective. It's reported that it previously hid all
unused parameter warnings though it doesn't seem to on any compiler I'm
currently using.
I've included -Wno-unused-parameter with the changes g
Hello all;
I've noticed that I can't seem to use ctrl-\ to get a stack dump of long
running java processes (mostly the jdk javac compile) using the new build.
Instead I get something like:
make: *** [jdk-only] Quit (core dumped)
mike@samuel:~/code/jdk/jdk9-dev$ ./jdk9-dev/common/bin/logger.sh:
Looks like good cleanup.
Could some of the implementation of BOOTJDK_CHECK_TOOL_IN_BOOTJDK be replaced
with a call to AC_CHECK_PROG? (It may not be worth the trouble).
Mike
On Jan 29 2014, at 04:06 , Magnus Ihse Bursie
wrote:
> Bug: https://bugs.openjdk.java.net/browse/JDK-8033119
>
> The f
I can't verify that the changes are correct but the resulting build does seem
to work for me.
Can you remove this (now) inaccurate comment in Hasher.java :
46 // This class cannot, sadly, make use of 1.5 features since it must be
47 // compiled and run with the bootstrap JDK, which i
Looks fine.
On Jan 29 2014, at 03:13 , Magnus Ihse Bursie
wrote:
> Bug: https://bugs.openjdk.java.net/browse/JDK-8033115
>
> Due to a bad merge between 8027584 and 8031759, configure fails.
>
> The merge auto-applied, so I didn't think there would be any problems. But
> there was a missing S
On Jan 28 2014, at 17:50 , Magnus Ihse Bursie
wrote:
>
> On 2014-01-29 01:44, Mike Duigou wrote:
>> Looks fine. (I have been caught by the Windows cygwin issue as well).
>>
>> Do you want to do away with the performance hints entirely? I had another
>> patch f
Looks fine. (I have been caught by the Windows cygwin issue as well).
Do you want to do away with the performance hints entirely? I had another patch
for setting memsize which added other hints.
Mike
On Jan 28 2014, at 15:31 , Magnus Ihse Bursie
wrote:
> Bug: https://bugs.openjdk.java.net/br
I really prefer the enhanced semantics!
- another non-autoconf option to configure to force regeneration of
generated-configure would be nice. ("--force-autogen" perhaps?) Applying
patches (such as this one) I sometimes find that the timestamp check gets
confused and fails to regen. "touch comm
The change works for me and does meet the needs I was trying to address in
8031669.
Could you include the addition of [greadlink readlink] that was in my patch?
The Mac version of this tool from either fink or macports is named greadlink
and has advantages over the manual resolution method (mos
On Jan 15 2014, at 00:48 , Erik Joelsson wrote:
>
> On 2014-01-14 20:59, Mike Duigou wrote:
>> On Jan 14 2014, at 10:35 , Mike Duigou wrote:
>>
>> I discovered the problem.
>>
>> CAT=foo sh configure
>>
>> will result in
>>
>> C
On Jan 14 2014, at 10:35 , Mike Duigou wrote:
>
> On Jan 14 2014, at 05:17 , Magnus Ihse Bursie
> wrote:
>
>> On 2014-01-14 02:57, Mike Duigou wrote:
>>> Hello all;
>>>
>>> This changeset allows overriding of the "
On Jan 14 2014, at 10:35 , Mike Duigou wrote:
>
> On Jan 14 2014, at 05:17 , Magnus Ihse Bursie
> wrote:
>
>> On 2014-01-14 02:57, Mike Duigou wrote:
>>> Hello all;
>>>
>>> This changeset allows overriding of the "
On Jan 14 2014, at 05:17 , Magnus Ihse Bursie
wrote:
> On 2014-01-14 02:57, Mike Duigou wrote:
>> Hello all;
>>
>> This changeset allows overriding of the "simple required tools" which are
>> gathered in BASIC_SETUP_FUNDAMENTAL_TOOLS macro of basic
ich could control the language used.
> I would rather avoid having to do that in the future.
>
> /Erik
>
> On 2014-01-14 08:57, Magnus Ihse Bursie wrote:
>> On 2014-01-14 02:46, Mike Duigou wrote:
>>> Hello all;
>>>
>>> This is a very small change.
Hello all;
This changeset allows overriding of the "simple required tools" which are
gathered in BASIC_SETUP_FUNDAMENTAL_TOOLS macro of basics.m4 I didn't extend
the override ability to every tool, instead primarily to the file manipulation
and archiving tools which I need to override for a pro
1 - 100 of 268 matches
Mail list logo
