On 2013-10-04 21:58, Francis ANDRE wrote:
Hi
I am trying to build a webrev for an outgoing patch on a
WXP/x86/Cygwin platform, but it seems that the webrev script is not
handling properly the /cygdrive/ path. So, I am wondering if there a
specific configuration guide for using this script
On 2013-10-06 05:19, David Holmes wrote:
Magnus,
Echoing Naoto's comments I don't agree that we should be supporting
this. In the original email a workaround was mentioned using an
environment variable - if that is the case then I don't think we need
to do anything here. Even if not, who
I installed pdksh from obsolete cygwin packages and it's working fine,
like pdksh /usr/bin/webrev.ksh ..., ksh (which is mksh I believe) is
not working for me.
Thanks,
Vadim
On 07.10.2013 11:32, Magnus Ihse Bursie wrote:
On 2013-10-04 21:58, Francis ANDRE wrote:
Hi
I am trying to build a
This patch changes the behavior of --with-build-number and
--with-user-release-suffix. Previously, you could only set one or the
other and setting build-number would override user-release-suffix. With
this patch it's possible to set both. This simplifies nightly builds of
various group forests
On 2013-10-07 14:21, Erik Joelsson wrote:
This patch changes the behavior of --with-build-number and
--with-user-release-suffix. Previously, you could only set one or the
other and setting build-number would override user-release-suffix.
With this patch it's possible to set both. This
Erik:
On 10/ 7/13 05:44 AM, Magnus Ihse Bursie wrote:
On 2013-10-07 14:21, Erik Joelsson wrote:
This patch changes the behavior of --with-build-number and
--with-user-release-suffix. Previously, you could only set one or the
other and setting build-number would override user-release-suffix.
Unfortunately, the patch failed when I tried submitting it. Usage of the
ListPathsSafely macro in SetupArchive is a bit different and needs to be
adjusted. Here is a webrev that I have verified to work:
http://cr.openjdk.java.net/~erikj/8025921/webrev.root.01/
I also reduced duplication and
Le 07/10/2013 11:32, Magnus Ihse Bursie a écrit :
On 2013-10-06 05:19, David Holmes wrote:
Magnus,
Echoing Naoto's comments I don't agree that we should be supporting this. In
the original email a workaround was mentioned using an environment variable -
if that is the case then I don't
Hi Magnus,
I think we need to make it clear that the locale we support for building
the JDK is US English, which is proven to work, and it should be
documented in README-builds.html or similar. Your change in configure
script looks good, in order for passing non-English CL.EXE through, but
I
