Apologies all
On Tue, Oct 5, 2021 at 10:35 AM Bruno Borges wrote:
>
> ---
> *Bruno Borges*
> brunoborges.io
>
Hi,
Could I have review of a typo.
Testing: jdk/jdk/jfr
Thanks
Erik
-
Commit messages:
- Initial
Changes: https://git.openjdk.java.net/jdk/pull/5803/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5803&range=00
Issue: https://bugs.openjdk.java.net/browse/JDK-82745
nd all X11 headers (shape.h Xrender.h Xrandr.h
> XTest.h Intrinsic.h).
>
> I wondered about the missing package help output, we should display some hint
> what packages are missing.
> In help.m4, PKGHANDLER was detected as /usr/bin/zypper .
> However only the exact string zyppe
On Fri, 23 Jul 2021 08:30:28 GMT, Christoph Langer wrote:
> > Hi Christoph, thanks for looking into it. Should we do the same for the
> > other package managers in the case statement (like yum, apt-get) as well ?
> > I only observed it on SLES15 (where zypper was detected) but it might be
> >
Intrinsic.h).
>
> I wondered about the missing package help output, we should display some hint
> what packages are missing.
> In help.m4, PKGHANDLER was detected as /usr/bin/zypper .
> However only the exact string zypper is checked, this should be relaxed.
> Afterwards,
rror: Could not find all X11 headers (shape.h Xrender.h Xrandr.h
>> XTest.h Intrinsic.h).
>>
>> I wondered about the missing package help output, we should display some
>> hint what packages are missing.
>> In help.m4, PKGHANDLER was detected as /usr/bin/zypper .
On Fri, 23 Jul 2021 08:18:48 GMT, Matthias Baesken wrote:
> > Makes sense to me.
>
> Hi Christoph, thanks for looking into it. Should we do the same for the other
> package managers in the case statement (like yum, apt-get) as well ? I only
> observed it on SLES15 (where zypper was detected) b
On Fri, 23 Jul 2021 08:12:21 GMT, Christoph Langer wrote:
> Makes sense to me.
Hi Christoph, thanks for looking into it. Should we do the same for the other
package managers in the case statement (like yum, apt-get) as well ? I only
observed it on SLES15 (where zypper was detected) but it
nd all X11 headers (shape.h Xrender.h Xrandr.h
> XTest.h Intrinsic.h).
>
> I wondered about the missing package help output, we should display some hint
> what packages are missing.
> In help.m4, PKGHANDLER was detected as /usr/bin/zypper .
> However only the exact string zyppe
missing package help output, we should display some hint
what packages are missing.
In help.m4, PKGHANDLER was detected as /usr/bin/zypper .
However only the exact string zypper is checked, this should be relaxed.
Afterwards, the package - help was working nicely :
checking for X11/extensions
On 2020-05-06 10:52, Severin Gehwolf wrote:
On Wed, 2020-05-06 at 10:16 +0200, Magnus Ihse Bursie wrote:
On 2020-05-05 17:15, Severin Gehwolf wrote:
Hi,
Could I please get a review of this trivial change? Apparently using
the help builtin for determining whether or not a builtin is available
On Wed, 2020-05-06 at 10:16 +0200, Magnus Ihse Bursie wrote:
> On 2020-05-05 17:15, Severin Gehwolf wrote:
> > Hi,
> >
> > Could I please get a review of this trivial change? Apparently using
> > the help builtin for determining whether or not a builtin is available
>
On 2020-05-05 17:15, Severin Gehwolf wrote:
Hi,
Could I please get a review of this trivial change? Apparently using
the help builtin for determining whether or not a builtin is available
is not a good idea. A more portable way to do this is to use "command
-v" or "type"
On Tue, 2020-05-05 at 08:24 -0700, Erik Joelsson wrote:
> Looks good to me.
Thanks for the review, Erik!
Cheers,
Severin
> /Erik
>
> On 2020-05-05 08:15, Severin Gehwolf wrote:
> > Hi,
> >
> > Could I please get a review of this trivial change? Apparently
Looks good to me.
/Erik
On 2020-05-05 08:15, Severin Gehwolf wrote:
Hi,
Could I please get a review of this trivial change? Apparently using
the help builtin for determining whether or not a builtin is available
is not a good idea. A more portable way to do this is to use "command
-
Hi,
Could I please get a review of this trivial change? Apparently using
the help builtin for determining whether or not a builtin is available
is not a good idea. A more portable way to do this is to use "command
-v" or "type". Thanks to Michael Zucchi for contributing t
Looks good.
/Erik
On 2020-03-11 02:54, Magnus Ihse Bursie wrote:
I unfortunately forget a comma in two places in JDK-8240820, which
makes the help output incorrect.
Bug: https://bugs.openjdk.java.net/browse/JDK-8240866
Patch inline:
diff --git a/make/autoconf/flags-cflags.m4
b/make/autoconf
I unfortunately forget a comma in two places in JDK-8240820, which makes
the help output incorrect.
Bug: https://bugs.openjdk.java.net/browse/JDK-8240866
Patch inline:
diff --git a/make/autoconf/flags-cflags.m4 b/make/autoconf/flags-cflags.m4
--- a/make/autoconf/flags-cflags.m4
+++ b/make
: Montag, 4. März 2019 18:21
To: Baesken, Matthias ; Magnus Ihse Bursie
; 'build-dev@openjdk.java.net'
Cc: Simonis, Volker ; Zeller, Arno
Subject: Re: RFR: 8219920: dependency help output in configure-step :
support zypper tool
Hello,
I noted that you put zypper first in help.m4, but
c: Simonis, Volker ; Zeller, Arno
Subject: Re: RFR: 8219920: dependency help output in configure-step :
support zypper tool
Hello,
I noted that you put zypper first in help.m4, but apt-get is still ahead
in configure. I think we should try to keep them in the same order in
both files. Otherwise this
Magnus Ihse Bursie
> ; 'build-dev@openjdk.java.net' d...@openjdk.java.net>
> Cc: Simonis, Volker ; Zeller, Arno
>
> Subject: Re: RFR: 8219920: dependency help output in configure-step :
> support zypper tool
>
> Hello,
>
> I noted that you put zypp
OpenSUSE Leap 15 with not many
packages installed .
I observed some things :
* Latest OpenSUSE Leap 15 had “apt-get” as well additionally to zypper
; however the apt-get Ubuntu package names do not help much on SUSE - so
I put zypper in the search list in front of apt-get
Hi Magnus , I tested a bit more on a recent OpenSUSE Leap 15 with not many
packages installed .
I observed some things :
* Latest OpenSUSE Leap 15 had “apt-get” as well additionally to zypper
; however the apt-get Ubuntu package names do not help much on SUSE - so
I put
. März 2019 14:46
*To:* Baesken, Matthias ;
'build-dev@openjdk.java.net'
*Cc:* Simonis, Volker ; Zeller, Arno
*Subject:* Re: RFR: 8219920: dependency help output in configure-step
: support zypper tool
On 2019-03-01 09:48, Baesken, Matthias wrote:
Btw. Speaking about help.m4 h
jdk/jdk it probably does not make much sense and the URLs are the way to go .
Best regards, Matthias
From: Magnus Ihse Bursie
Sent: Freitag, 1. März 2019 14:46
To: Baesken, Matthias ; 'build-dev@openjdk.java.net'
Cc: Simonis, Volker ; Zeller, Arno
Subject: Re: RFR: 8219920: depen
could try to test on a fresh OpenSUSE .
Best regards,
Matthias
From: Magnus Ihse Bursie
Sent: Freitag, 1. März 2019 14:44
To: Baesken, Matthias ; 'build-dev@openjdk.java.net'
Cc: Simonis, Volker ; Zeller, Arno
Subject: Re: RFR: 8219920: dependency help output in conf
On 2019-03-01 14:46, Magnus Ihse Bursie wrote:
On 2019-03-01 09:48, Baesken, Matthias wrote:
Btw. Speaking about help.m4 help output , the mentioning of
openjdk-8-jdk in the various package-installer help outputs seems
to be outdated and misleading to me :
88 apt_help() {
89
On 2019-03-01 09:48, Baesken, Matthias wrote:
Btw. Speaking about help.m4 help output , the mentioning of openjdk-8-jdk
in the various package-installer help outputs seems to be outdated and
misleading to me :
88 apt_help() {
89 case $1 in
. . .
94 openjdk)
95
On 2019-02-28 13:53, Baesken, Matthias wrote:
Hello, please review the following change .
Currently the configure-step outputs help for a number of packages +
related installation calls in case of missing dependencies (like cups / alsa
etc.) .
This help output step covers a few
Btw. Speaking about help.m4 help output , the mentioning of openjdk-8-jdk
in the various package-installer help outputs seems to be outdated and
misleading to me :
88 apt_help() {
89 case $1 in
. . .
94 openjdk)
95 PKGHANDLER_COMMAND="sudo apt-get in
Hello, please review the following change .
Currently the configure-step outputs help for a number of packages +
related installation calls in case of missing dependencies (like cups / alsa
etc.) .
This help output step covers a few tools (like apt-get).
However the OpenSUSE
On 1/28/19 1:26 AM, Severin Gehwolf wrote:
Hi Alan, Mandy,
On Sun, 2019-01-27 at 08:14 +, Alan Bateman wrote:
On 26/01/2019 00:06, Mandy Chung wrote:
Hi Severin,
Another alternative would be to support per-jlink-plugin resource
bundle to avoid merging .properties files at build time.
On Mon, 2019-01-28 at 14:40 +, Alan Bateman wrote:
> On 28/01/2019 09:26, Severin Gehwolf wrote:
> > :
> > > I skimmed the current patch and I see the usability has improved since
> > > the original proposal. It would be nice to get to
> > > `--strip-native-debug-symbols` without needing the "=
On 28/01/2019 09:26, Severin Gehwolf wrote:
:
I skimmed the current patch and I see the usability has improved since
the original proposal. It would be nice to get to
`--strip-native-debug-symbols` without needing the "=defaults" suffix.
There are details around the sub-options and naming that I
Hi Alan, Mandy,
On Sun, 2019-01-27 at 08:14 +, Alan Bateman wrote:
> On 26/01/2019 00:06, Mandy Chung wrote:
> > Hi Severin,
> >
> > Another alternative would be to support per-jlink-plugin resource
> > bundle to avoid merging .properties files at build time. The
> > plugin-specific messages
properties into actual ListResourceBundle Java classes.
> >
> > The copying from the src tree to the gensrc tree doesn't seem to
> > work.
> > I've tried using $(CP) and SetupCopyFiles to no avail. Would
> > anybody
> > willing to help?
> >
> > WIP webrev is:
> >
http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8214796-wip/01/webrev/
> >
> > I thought I'd do the copying in an else branch in
> > SetupPropertiesMerge,
> > where I've put in a FIXME comment. Am I on the wrong track?
> >
> > Thanks,
> > Severin
> >
> > The copying from the src tree to the gensrc tree doesn't seem to
> > work.
> > I've tried using $(CP) and SetupCopyFiles to no avail. Would
> > anybody
> > willing to help?
> SetupCopyFile should work, but in this case I think it's simples
On 26/01/2019 00:06, Mandy Chung wrote:
Hi Severin,
Another alternative would be to support per-jlink-plugin resource
bundle to avoid merging .properties files at build time. The
plugin-specific messages should only be used by the plugin itself
and it would be cleaner for each plugin to manage
rties into actual ListResourceBundle Java classes.
The copying from the src tree to the gensrc tree doesn't seem to work.
I've tried using $(CP) and SetupCopyFiles to no avail. Would anybody
willing to help?
WIP webrev is:
http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8214796-wip/01/web
d just get
copied to support/gensrc and that source root be used for compiling
those properties into actual ListResourceBundle Java classes.
The copying from the src tree to the gensrc tree doesn't seem to work.
I've tried using $(CP) and SetupCopyFiles to no avail. Would anybody
willing
iling
those properties into actual ListResourceBundle Java classes.
The copying from the src tree to the gensrc tree doesn't seem to work.
I've tried using $(CP) and SetupCopyFiles to no avail. Would anybody
willing to help?
SetupCopyFile should work, but in this case I think it's s
undle Java classes.
The copying from the src tree to the gensrc tree doesn't seem to work.
I've tried using $(CP) and SetupCopyFiles to no avail. Would anybody
willing to help?
WIP webrev is:
http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8214796-wip/01/webrev/
I thought I'd do th
And see whether your problem is addressed? (seems so on my machine)
Hope this helps
Maurizio
On 24/09/18 10:29, Magnus Ihse Bursie wrote:
Hi compiler folks!
Could anyone possibly help me with having a look at
https://bugs.openjdk.java.net/browse/JDK-8211057? The
CompileProperties build tool helpe
Hi compiler folks!
Could anyone possibly help me with having a look at
https://bugs.openjdk.java.net/browse/JDK-8211057? The CompileProperties
build tool helper is not generating reproducible output, that is, if you
run it multiple times one after another, with no source code changes, it
On 2016-06-27 01:40, David Holmes wrote:
Hi Tim,
On 25/06/2016 10:52 AM, Tim Bell wrote:
Hello
Please review this added sanity check for the Solaris assembler (as).
'as' is not installed by default on Solaris, and it would be better to
fail fast if missing.
Looks good to me too.
Fix look
Hi Tim,
On 25/06/2016 10:52 AM, Tim Bell wrote:
Hello
Please review this added sanity check for the Solaris assembler (as).
'as' is not installed by default on Solaris, and it would be better to
fail fast if missing.
Fix looks good. Makes me wonder what else may be missing by default - eg
G
Hello
Please review this added sanity check for the Solaris assembler (as).
'as' is not installed by default on Solaris, and it would be better to
fail fast if missing.
Bug report:
https://bugs.openjdk.java.net/browse/JDK-8081676
Webrev:
http://cr.openjdk.java.net/~tbell/8081676/
Note:
://cr.openjdk.java.net/~ihse/JDK-8138627-configure-help-for-reduced-build/webrev.01
/Magnus
When building reduced builds on Ubuntu, gcc-multilib and g++-multilib
needs to be installed. Inform the user about this if the build fails.
Bug: https://bugs.openjdk.java.net/browse/JDK-8138627
WebRev:
http://cr.openjdk.java.net/~ihse/JDK-8138627-configure-help-for-reduced-build/webrev.01
software\JavaFX\modules\media\src\main\native\gstreamer\projects\win\glib-lite.
> The errors look like:
> /bin/sh: cygpath: command not found
> /Makefile:71: recipe for target '/libglib-2.28.8.lib' failed/ /( I have
> messed up the line numbers ignore 71)/
> And make
ommand not found
/Makefile:71: recipe for target '/libglib-2.28.8.lib' failed/ /( I
have messed up the line numbers ignore 71)/
And make returns 2 and error 127. Now from the cywin window, I can do
/Robin@MY-PC /cygdrive/e/robins_root/software/JavaFX//
//$ cygpath --help//
//cygpath
Looks good to me.
/Erik
On 2014-02-14 23:26, Mike Duigou wrote:
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
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 di
There are 6 dlls in the test directory
./jdk/test/sun/security/pkcs11/nss/lib/windows-i586/libnspr4.dll
./jdk/test/sun/security/pkcs11/nss/lib/windows-i586/libplc4.dll
./jdk/test/sun/security/pkcs11/nss/lib/windows-i586/libplds4.dll
./jdk/test/sun/security/pkcs11/nss/lib/windows-i586/nss3.dll
./j
IIRC, and in case it wasn't clear from reading the responses, the
permission changes are done by the Makefiles (e.g.
jdk/test/Makefile:193), and not by JTREG itself.
I agree with Jon's comment, perhaps a .dll copy to the temporary working
directory is in order. That would save people trying t
It should also be the case that the tests should run if the entire test/
directory (all files and directories) were readonly, so if code is
modifying files in place or creating new files anywhere in the test
directory, that should be regarded as a Bad Thing and fixed.
-- Jon
On 12/04/2013 10
Agreed with Magnus the setting of the executable bits should be made
explicitly somewhere to avoid such error...
Francis
Le 04/12/2013 19:05, Magnus Ihse Bursie a écrit :
So at least you find a likely cause for the issues Francis are seeing. :)
It feels a bit weird juggling around with p
So at least you find a likely cause for the issues Francis are seeing. :)
It feels a bit weird juggling around with permissions like that, but maybe
there was no clear use-case for running this from hg?
/Magnus
> 4 dec 2013 kl. 16:38 skrev Mike Duigou :
>
>
>> On Dec 4 2013, at 06:06 , Magnus
On Dec 4 2013, at 06:06 , Magnus Ihse Bursie
wrote:
> On 2013-11-22 10:12, Mike Duigou wrote:
>> the jdk/test/Makefile is normally responsible for setting the executable
>> flags on those files but only does so before running the tests. If you are
>> executing jtreg directly then the files ar
On 2013-11-22 10:12, Mike Duigou wrote:
the jdk/test/Makefile is normally responsible for setting the executable flags
on those files but only does so before running the tests. If you are executing
jtreg directly then the files aren't being made executable.
Hm, are you saying jtreg is setting
the jdk/test/Makefile is normally responsible for setting the executable flags
on those files but only does so before running the tests. If you are executing
jtreg directly then the files aren't being made executable.
Mike
On Nov 21 2013, at 20:49 , Francis ANDRE
wrote:
> Hi
>
> Running Tes
Hi
Running TestInterop from the PKCS#11 test suite on a WXP/Cygwin/VS2010 platform,
one gets this exception
Caused by: java.io.IOException: Accès
refusé.Z:\JDK\jdk8\jdk\test\sun\security\pkcs11\nss\lib\windows-i586\softokn3.dll
This exception appears because all dlls in the directory
jdk8\
I did some experiments and looked closer at the code. I missed some
details in my earlier analysis. Here is what is supposed to happen:
FullPath is a macro that takes a path and converts it to mixed style
(c:/) path without spaces. Depending on whether the input contains a
space (the test $(if
I remember cygwin having some goofy behaviors with upper case, e.g. for Z:/.
/cygdrive/Z/ vs. /cygdrive/z/
just a thought...
-kto
On Nov 20, 2013, at 12:11 PM, Francis ANDRE wrote:
> Erik
>
> >>How are you invoking the build to cause this error? Are you explicitly
> >>setting ALT_OUTPUTDIR
Erik
>>How are you invoking the build to cause this error? Are you explicitly
setting ALT_OUTPUTDIR?
I am invoking just: make sanity without explicitly setting ALT_OUTPUTDIR.
What is the path to your workspace?
FrancisANDRE@idefix /cygdrive/Z/JDK/jdk7u
$ hg path
default = http://hg.openjdk.ja
The way I understand it $(if $(word 2,$1) is a check for whitespace in
the input parameter. It's an optimization to avoid executing cygpath
when it's not needed. The MixedPath macro cannot be used if the path
contains a space. It also doesn't convert to an absolute path, just
replacing cygwin s
Hi
I am trying to fix the following error
$ make sanity
jdk/make/common/shared/Defs.gmk:563: *** "ERROR: Trouble with the absolute path
for OUTPUTDIR './bui
ld/windows-i586'". Stop.
and found the following code in jdk/make/common/shared/Defs-windows.gmk, line
109
define FullPath
$(if $(wor
On Nov 5 2013, at 09:37 , Francis ANDRE
wrote:
> Mike
> Le 05/11/2013 07:16, Mike Duigou a écrit :
>>> Hi
>>>
>>> Using a fresh copy of the jdk7u repository, and running make -d sanity, I
>>> got the error below. Why OUTPUTDIR must be absolute or if it must be
>>> absolute, why it is not whe
Mike
Le 05/11/2013 07:16, Mike Duigou a écrit :
Hi
Using a fresh copy of the jdk7u repository, and running make -d sanity, I got
the error below. Why OUTPUTDIR must be absolute or if it must be absolute, why
it is not when running make sanity?
In general, using absolute paths always helps for
On Nov 4 2013, at 21:39 , Francis ANDRE
wrote:
> Hi
>
> Using a fresh copy of the jdk7u repository, and running make -d sanity, I got
> the error below. Why OUTPUTDIR must be absolute or if it must be absolute,
> why it is not when running make sanity?
In general, using absolute paths alway
Hi
Using a fresh copy of the jdk7u repository, and running make -d sanity, I got
the error below. Why OUTPUTDIR must be absolute or if it must be absolute, why
it is not when running make sanity?
It seems to me that OUTPUTDIR is computed in the jdk subdirectory makefiles
while it is not in t
Changeset: dffe654ab24c
Author:ihse
Date: 2013-10-22 11:12 +0200
URL: http://hg.openjdk.java.net/jdk8/build/rev/dffe654ab24c
8001925: Add useful help messages if freetype is not found on Windows
Reviewed-by: erikj, tbell
! common/autoconf/generated-configure.sh
! common/autoconf
instructions on how to proceed.
WebRev:
http://cr.openjdk.java.net/~ihse/JDK-8001925-add-help-for-freetype-on-windows/webrev.01
/Magnus
-8001925-add-help-for-freetype-on-windows/webrev.01
/Magnus
Bug: https://bugs.openjdk.java.net/browse/JDK-8001925
When freetype is not found on Windows (a requirement for OpenJDK
builds), give informative instructions on how to proceed.
WebRev:
http://cr.openjdk.java.net/~ihse/JDK-8001925-add-help-for-freetype-on-windows/webrev.01
/Magnus
Hi Mike:
Another tiny changeset with updates to the make help target. This change publicizes the
"docs" target and updates the list of components for component specific targets.
http://cr.openjdk.java.net/~mduigou/JDK-8023433/0/webrev/
This change would be integrated via the TL re
Hello all;
Another tiny changeset with updates to the make help target. This change
publicizes the "docs" target and updates the list of components for component
specific targets.
http://cr.openjdk.java.net/~mduigou/JDK-8023433/0/webrev/
This change would be integrated via the TL re
Hi,
On 17/08/2013 10:56 PM, lux-integ wrote:
Greetings,
I downloaded the latest openJDK8 sources from the mercurial repository
earlier. I tried using the configure script with the options
/bin/sh configure \
--with-dev-kit=/path/to/'where I want to put openjdk' \
No, --with-dev-kit is used
Greetings,
I downloaded the latest openJDK8 sources from the mercurial repository
earlier. I tried using the configure script with the options
/bin/sh configure \
--with-dev-kit=/path/to/'where I want to put openjdk' \
--with-cacerts=/path-to/sslCAcerts
( plus other options obtained
from the
in the readme
*cd test && make PRODUCT_HOME=`pwd`/../build/*/images/j2sdk-image all
*still fails because it is still trying to look in
/usr/bin/win32/bin/jtreg
and win32/bin/jtreg does not exist.
Any help would be greatly welcome but if possible I don't want to have to
install jtreg from s
t;
> >
> > which made it detect jtreg but the command in the readme
> > *cd test && make PRODUCT_HOME=`pwd`/../build/*/images/j2sdk-image all
> >
> > *still fails because it is still trying to look in
> > /usr/bin/win32/bin/jtreg
> >
> > and win32/bin/jtreg does not exist.
> >
> > Any help would be greatly welcome but if possible I don't want to have to
> > install jtreg from source as that is a whole other can of worms.
> >
> > Thank you,
> > Matthew
>
>
& make PRODUCT_HOME=`pwd`/../build/*/images/j2sdk-image all
>
> *still fails because it is still trying to look in
> /usr/bin/win32/bin/jtreg
>
> and win32/bin/jtreg does not exist.
>
> Any help would be greatly welcome but if possible I don't want to have to
> install jtreg from source as that is a whole other can of worms.
>
> Thank you,
> Matthew
*cd test && make PRODUCT_HOME=`pwd`/../build/*/images/j2sdk-image all
*still fails because it is still trying to look in
/usr/bin/win32/bin/jtreg
and win32/bin/jtreg does not exist.
Any help would be greatly welcome but if possible I don't want to have to
install jtreg from source as
mage all
*still fails because it is still trying to look in
/usr/bin/win32/bin/jtreg
and win32/bin/jtreg does not exist.
Any help would be greatly welcome but if possible I don't want to have to
install jtreg from source as that is a whole other can of worms.
Thank you,
Matthew
dk/pages/MakeImages)
Appreciate all the help in advance.
Regards,
Kalyan
ror 2
make: *** [jdk-only] Error 2
I have cloned from
hg clone http://hg.openjdk.java.net/jdk8/tl jdk8_tl
and I am following instructions posted at(
https://java.net/projects/adoptopenjdk/pages/MakeImages)
Appreciate all the help in advance.
Regards,
Kalyan
information about
the configurations was relatively unadorned.
Mike
On Feb 23 2013, at 09:29 , Martin Buchholz wrote:
I'm having fun with the shiny new build system.
It took me a while to discover that "make help" was exceptionally helpful.
However, I was interested in passing a c
2013, at 09:29 , Martin Buchholz wrote:
> I'm having fun with the shiny new build system.
> It took me a while to discover that "make help" was exceptionally helpful.
>
> However, I was interested in passing a configuration to CONF= and was
> annoyed there was no cl
I'm having fun with the shiny new build system.
It took me a while to discover that "make help" was exceptionally helpful.
However, I was interested in passing a configuration to CONF= and was
annoyed there was no clue what to provide. (I wasn't even sure exactly
what a
On Apr 26, 2012, at 12:37 AM, Magnus Ihse Bursie wrote:
> On 2012-04-25 21:34, Kelly O'Hair wrote:
>> I of course approve. ;^)
>>
>> We need some code phrase for me when you want a patch integrated into the
>> jdk8/build forest.
>> I'll deal with the CR, make the owner you in this case, and add
On 2012-04-25 21:34, Kelly O'Hair wrote:
I of course approve. ;^)
We need some code phrase for me when you want a patch integrated into the
jdk8/build forest.
I'll deal with the CR, make the owner you in this case, and add any reviewers I
have seen in the email
thread. So how about a code phr
I of course approve. ;^)
We need some code phrase for me when you want a patch integrated into the
jdk8/build forest.
I'll deal with the CR, make the owner you in this case, and add any reviewers I
have seen in the email
thread. So how about a code phrase like "Kelly, Please integrate this patc
Magnus,
On 2012-04-25 20:31, Magnus Ihse Bursie wrote:
> Hence, every time configure.ac is modified, configure will be updated as
> well.
OK. Thank you for the explanation!
-Dmitry
>
> /Magnus
>>
>> -Dmitry
>>
>>
>> On 2012-04-25 17:32, Magnus Ihse Bursie wrote:
>>> On 2012-04-23 18:01, Dmit
25 apr 2012 kl. 17:23 skrev Dmitry Samersoff :
> Magnus,
>
> Fix looks good for me.
>
> The only question - why we should patch both configure.ac
> and configure ?
>
> I believe we generate configure from configure.ac
Yes we do, but we keep a generated configure checked in in the repo, so user
Magnus,
Fix looks good for me.
The only question - why we should patch both configure.ac
and configure ?
I believe we generate configure from configure.ac
-Dmitry
On 2012-04-25 17:32, Magnus Ihse Bursie wrote:
> On 2012-04-23 18:01, Dmitry Samersoff wrote:
>> Magnus,
>>
>> I'm second to Kelly
Looks much better, thanks Magnus.
-Chris.
On 25/04/2012 14:32, Magnus Ihse Bursie wrote:
On 2012-04-23 18:01, Dmitry Samersoff wrote:
Magnus,
I'm second to Kelly.
We shouldn't have executable scripts in repository.
Ok, so here comes a new, even simpler patch. :-)
http://cr.openjdk.java.net
On 2012-04-23 18:01, Dmitry Samersoff wrote:
Magnus,
I'm second to Kelly.
We shouldn't have executable scripts in repository.
Ok, so here comes a new, even simpler patch. :-)
http://cr.openjdk.java.net/~ihse/logger.sh-missing-x-permission/webrev.01/
/Magnus
Magnus,
I'm second to Kelly.
We shouldn't have executable scripts in repository.
-Dmitry
On 2012-04-23 10:16, Kelly O'Hair wrote:
If this file can never really have execute permission in the repositories, then
encouraging people to put
execute permission on it creates a risk that they might
If this file can never really have execute permission in the repositories, then
encouraging people to put
execute permission on it creates a risk that they might try to commit that
change, and then their changeset would get
rejected. A big annoyance.
So why not just always run $(SH) and skip th
On 21/04/2012 12:14 AM, Magnus Ihse Bursie wrote:
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 t
1 - 100 of 168 matches
Mail list logo
