I don't believe this has been properly addressed yet, but there are a
couple of ways to change the flags to javac that work now. Note that
these variables might change and we aren't officially declaring this as
a supported method.
JAVAC_FLAGS is added to all javac command lines. It's defined i
There have been some concerns raised about partial builds going away
when switching to the new build. Sjavac is supposed to solve this
problem once and for all, but since it most probably won't be there from
day one, I'm going to describe the workaround that has been implemented
to alleviate th
Thanks Erik,
I haven't tried this yet, but this is exactly what I was looking for (
some way to be partial builds ).
-Chris.
On 12/21/2012 09:39 AM, Erik Joelsson wrote:
There have been some concerns raised about partial builds going away
when switching to the new build. Sjavac is supposed t
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
On 21/12/2012 12:58, Fredrik Öhrström wrote:
:
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 packages, if the public api of java.awt was changed,
you need to know the 79 other packages
On Dec 20, 2012, at 10:18 PM, David Holmes wrote:
> webrevs:
>
> top-level repo: http://cr.openjdk.java.net/~dholmes/8004265/webrev.top/
These comments in Main.gmk don't seem to make sense:
117 # Note: This double-colon rule is intentional, to support
118 # custom make file integration.
119
Ok. That helps alot. Thanks. Looks good.
-kto
On Dec 19, 2012, at 1:16 AM, Erik Joelsson wrote:
> Oh, I will explain it.
>
> So, on all other platforms, this is the dependency chain (simplified,
> skipping the actual recipe rules):
>
> BUILD_LIBFDLIBM:=/path/to/libfdlibm.a
> BUILD_LIBJAVA:
21 dec 2012 kl. 16:18 skrev Kelly O'Hair :
> These comments in Main.gmk don't seem to make sense:
>
> 117 # Note: This double-colon rule is intentional, to support
> 118 # custom make file integration.
> 119 images:: source-tips demos images-only
>
> Do lines 117 and 118 just need to be deleted?
On 22/12/2012 1:18 AM, Kelly O'Hair wrote:
On Dec 20, 2012, at 10:18 PM, David Holmes wrote:
webrevs:
top-level repo:http://cr.openjdk.java.net/~dholmes/8004265/webrev.top/
These comments in Main.gmk don't seem to make sense:
117 # Note: This double-colon rule is intentional, to support
11
On Dec 21, 2012, at 3:27 PM, David Holmes wrote:
> On 22/12/2012 1:18 AM, Kelly O'Hair wrote:
>>
>> On Dec 20, 2012, at 10:18 PM, David Holmes wrote:
>>
>>> webrevs:
>>>
>>> top-level repo:http://cr.openjdk.java.net/~dholmes/8004265/webrev.top/
>>
>> These comments in Main.gmk don't seem to m
On 22/12/2012 10:11 AM, Kelly O'Hair wrote:
On Dec 21, 2012, at 3:27 PM, David Holmes wrote:
On JarReorder.java, it seems like you have just deleted a warning that
someone explicitly asked for
a class to be included, and also explicitly asked for that class to be
excluded.
If we are changing the
On Dec 21, 2012, at 5:01 PM, David Holmes wrote:
> On 22/12/2012 10:11 AM, Kelly O'Hair wrote:
>> On Dec 21, 2012, at 3:27 PM, David Holmes wrote:
On JarReorder.java, it seems like you have just deleted a warning that
someone explicitly asked for
a class to be included, and also ex
12 matches
Mail list logo
