Hello,
Looks good to me, and as always, wonderful to see progress on this!
/Erik
On 2015-03-12 03:53, joe darcy wrote:
Hello,
With package filtering of doclint checking now available (JDK-8071851:
Provide filtering of doclint checking based on packages), the time has
come to enable a
(including nashorn-dev since a makefile there is touched)
When creating a Setup* macro that takes named parameters, like
SetupJavaCompilation, there is a lot of copied boilerplate code that
needs to be written. The code, which is essentially copied for all these
macro definitions, handles
OK I will remove 187 before pushing, but yes 219 was intentional ...
-phil.
On 3/11/2015 1:55 AM, Erik Joelsson wrote:
Hello,
Line 187 looks like debug output left about. Perhaps also 219 but I
think that echo makes sense to keep. Otherwise looks good to me.
/Erik
On 2015-03-10 23:44,
On 2015-03-11 17:24, Tim Bell wrote:
Erik:
(including nashorn-dev since a makefile there is touched)
When creating a Setup* macro that takes named parameters, like
SetupJavaCompilation, there is a lot of copied boilerplate code that
needs to be written. The code, which is essentially copied
Thanks, I will correct those before pushing.
/Erik
On 2015-03-12 11:02, Magnus Ihse Bursie wrote:
On 2015-03-11 17:24, Tim Bell wrote:
Erik:
(including nashorn-dev since a makefile there is touched)
When creating a Setup* macro that takes named parameters, like
SetupJavaCompilation, there
On 2015-03-12 13:54, Staffan Larsen wrote:
The build for jconsole currently takes a template file and inserts the version
number of the build into the file. We can simplify this by removing the
template file and reading the java.runtime.version system property at runtime.
bug:
On 12/03/2015 12:54, Staffan Larsen wrote:
The build for jconsole currently takes a template file and inserts the version
number of the build into the file. We can simplify this by removing the
template file and reading the java.runtime.version system property at runtime.
bug:
Hi,
I understand that I'm a little late to the game but I just run into
this problem myself:)
The funny thing is that this problem doesn't occur with MinGW/MSYS but
just with Cygwin and I can't understand why?
We have a little special setup here at SAP: we do the Windows builds
with MinGW/MSYS
Volker,
What version of *make* do you use in both cases?
-Dmitry
On 2015-03-12 17:34, Volker Simonis wrote:
Hi,
I understand that I'm a little late to the game but I just run into
this problem myself:)
The funny thing is that this problem doesn't occur with MinGW/MSYS but
just with
Hi Dmitry,
no, they are not the same. I forgot to mention that.
On MinGW we have 3.81 and on Cygwin 4.1
Are there any known problems with the new Version?
I specially use GNU make 4.1 on Cygwin because it can nicely handle
: in target path names (unfortunately we still have them in our
build
Hi, Staffan.
bug: https://bugs.openjdk.java.net/browse/JDK-8075056
webrev: http://cr.openjdk.java.net/~sla/8075056/webrev.00/
http://cr.openjdk.java.net/~sla/8075056/webrev.00/
Looks good. I'm always happy to see changes where complexity is reduced.
Thanks,
iris
Looks good to me.
/Erik
On 2015-03-12 16:04, Magnus Ihse Bursie wrote:
With JDK-8074096, some warnings produced by libunpack was silenced.
However, it turned out that the version of clang shipped with Xcode
5.1 has some weird behavior, which I would classify as a compiler bug.
The generated
With JDK-8074096, some warnings produced by libunpack was silenced.
However, it turned out that the version of clang shipped with Xcode 5.1
has some weird behavior, which I would classify as a compiler bug. The
generated output differs markedly, if -Wno-foo is present on the command
line.
On 3/12/2015 5:54 AM, Staffan Larsen wrote:
The build for jconsole currently takes a template file and inserts the version
number of the build into the file. We can simplify this by removing the
template file and reading the java.runtime.version system property at runtime.
bug:
Looks good, jconsole now compile in Eclipse!
Erik
Staffan Larsen skrev 2015-03-12 13:54:
The build for jconsole currently takes a template file and inserts the
version number of the build into the file. We can simplify this by
removing the template file and reading the java.runtime.version
We have had issues before with pattern rules on Windows/cygwin. An older
incarnation of Images.gmk used pattern rules extensively, but it hanged or
crashed mysteriously.
Also, in general, we've tried to avoid pattern rules since they make it hard to
see what files are actually being
The build for jconsole currently takes a template file and inserts the version
number of the build into the file. We can simplify this by removing the
template file and reading the java.runtime.version system property at runtime.
bug: https://bugs.openjdk.java.net/browse/JDK-8075056
webrev:
Looks good.
/Erik
On 2015-03-12 13:54, Staffan Larsen wrote:
The build for jconsole currently takes a template file and inserts the version
number of the build into the file. We can simplify this by removing the
template file and reading the java.runtime.version system property at runtime.
18 matches
Mail list logo
