Re: Allow configure to detect if EC implementation is present
Hi, On 03/15/2013 07:15 AM, David Holmes wrote: > On 15/03/2013 7:04 PM, Erik Joelsson wrote: >> And as David pointed out, please notify me and Tim Bell when you push > > If I am added to that list we will have global timezone coverage :) > Though we should all see the push notifications anyway, it should > minimize the window of potential breakage. > > I think as long as the pushes are to jdk8/build that will also minimise > risk. Where we had problems last week was where pushes went to jdk8/tl. > That may still be needed in some cases, but for pure build changes > jdk8/build is best. I have pushed the changes: http://hg.openjdk.java.net/jdk8/build/rev/e2057191f6da http://hg.openjdk.java.net/jdk8/build/jdk/rev/624bcb480006 Thanks, Omair -- PGP Key: 66484681 (http://pgp.mit.edu/) Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681
Re: Allow configure to detect if EC implementation is present
You're correct Omar. That target directory is not always present as I had indicated below. The new and old builds are indeed consistent in the way they handle that. Thanks. On 14 Mar 2013, at 19:50, Omair Majid wrote: > On 03/14/2013 03:14 PM, Vincent Ryan wrote: >> The DISABLE_INTREE_EC flag is designed to control whether the Elliptic Curve >> support in the >> JDK source tree is skipped during a build. It is used to avoid the >> duplication of EC libraries on >> platforms where an EC library is already present. >> >> In the old build it was a build option. In the new build it appears to be >> controlled by the presence >> of a directory. That is incorrect as the directory is always present. The >> behaviour differs from the old build. > > FWIW, the current new-build and the current old-build both allow you to > specify 'make DISABLE_INTREE_EC=yes' and do the right thing. > > However, currently there is no way to say this using configure. The > patch I posted makes configure automatically set DISABLE_INTREE_EC=yes > if the directory is not found. The directory is always present in > OpenJDK8. However, some Linux distributions prefer to build with ECC > disabled due to legal reasons [1], and will remove the directory when > they create the OpenJDK8 source tarball. Where they had to delete the > directory _and_ set DISABLE_INTREE_EC before, with this patch they just > have to delete the directory. > > If you would like me to add a configure option to control this as well, > then I will be happy to add that too. May I do that as a separate patch? > > Thanks, > Omair > > [1] http://en.wikipedia.org/wiki/ECC_patents > > -- > PGP Key: 66484681 (http://pgp.mit.edu/) > Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681
Re: Allow configure to detect if EC implementation is present
On 15/03/2013 7:04 PM, Erik Joelsson wrote: And as David pointed out, please notify me and Tim Bell when you push If I am added to that list we will have global timezone coverage :) Though we should all see the push notifications anyway, it should minimize the window of potential breakage. I think as long as the pushes are to jdk8/build that will also minimise risk. Where we had problems last week was where pushes went to jdk8/tl. That may still be needed in some cases, but for pure build changes jdk8/build is best. Cheers, David this so we may have a chance at keeping the Oracle internal configure script up to date. Also please avoid pushing on a Wednesday as that's when the integration to master happens and the likelihood of bad timing increases. I don't like this complication any more than any of you, but for the time being, that's the way it is. /Erik
Re: Allow configure to detect if EC implementation is present
On 2013-03-14 20:37, Omair Majid wrote: Andrew Hughes wrote the original changeset in the old build system [1] and I believe this is exactly what he wanted out of the changeset. I am CC'ing Erik, who wrote the TODO [2] so he can clarify what he meant. I didn't actually create that comment in the first place, I just committed it as part of a big move of changes from the build-infra repos, where the work was done in small increments. Looking at this, I'm suspecting the comment was added due to this comment in jdk/make/sun/security/ec/Makefile: # # Some licensees do not get the native ECC sources, but we still need to # be able to build "all" for them. Check here to see if the sources are # available. If not, then skip them. # A usecase probably not that interesting to the OpenJDK community, but as Omair points out, it still applies, so I think this is a good idea. Adding a configure option for it would be nice too, but I don't see it as a requirement for this fix. I like the last suggestion with a clear yes/no with no double negatives, it looks ok. And as David pointed out, please notify me and Tim Bell when you push this so we may have a chance at keeping the Oracle internal configure script up to date. Also please avoid pushing on a Wednesday as that's when the integration to master happens and the likelihood of bad timing increases. I don't like this complication any more than any of you, but for the time being, that's the way it is. /Erik
Re: Allow configure to detect if EC implementation is present
- Original Message -
> On 15/03/2013 12:55 PM, Andrew Hughes wrote:
> > - Original Message -
> >> On 15/03/2013 5:37 AM, Omair Majid wrote:
> >>> Hi,
> >>>
> >>> Updated webrev at:
> >>> http://cr.openjdk.java.net/~omajid/webrevs/intree-ec/01/
> >>>
> >>> I switched from DISABLE_INTREE_EC to ENABLE_INTREE_EC to avoid
> >>> the
> >>> confusion with double negatives.
> >>
> >> Looking just at the mechanics of this it looks fine to me.
> >
> > I concur.
> >
> >> This needs to
> >> be coordinated with someone from the build team (which isn't me)
> >> so
> >> that we can keep the closed generated-configure.sh in sync.
> >
> > I don't think this is a reasonable requirement generally, though it
> > may be fine in this case. We should now be getting to the point
> > where an OpenJDK committer can post a patch, an OpenJDK reviewer
> > can review it and the committer can push it to an appropriate
> > repository without either of these people being Oracle employees.
> > Certainly, the bylaws allow this.
> >
> > What you're asking here seems no different than me asking for
> > someone to co-ordinate with the IcedTea team to update their
> > build machinery. I wouldn't expect this to happen and I don't
> > think
> > Oracle should either.
>
> We know this is a problem. Hopefully we will have a solution soon
> that
> will alleviate the need for this. In the meantime I would request
> your
> forbearance. I should have said "Can you please ..." rather than
> "This
> needs ...".
>
Thanks :-)
I'm just very wary of anything that looks like it will block people
getting involved in OpenJDK.
> >>
> >> Personally I wonder whether the existence check should be in the
> >> Makefile rather than done at configure time? I worry that we end
> >> up
> >> with too many make variables becoming configure variables as well.
> >>
> >
> > One of the main functions of a configure script is to make these
> > variables more easily accessible to the point that you should
> > only need to set make variables when you need to do a one-time
> > override
> > of something set by configure. We should no longer be passing a
> > huge
> > list of make variables.
>
> Totally agreed with the last point.
>
> But to me the division of labor between configure and make is not
> always
> clear.
>
It's often not for me either, and the problem is twofold if you have
an existing setup as with OpenJDK because you're not adding a new option
so much as deciding how to access an old one.
> David
> -
>
> > I'd argue that Omair's work could be extended, in a further patch,
> > so
> > that the option was set by --disable-intree-ec and the behaviour
> > seen here was just the default if the option wasn't specified.
> > Having configure options also acts as a means of documenting the
> > various build options (see configure --help), something which
> > doesn't happen when they are imposed via make.
>
>
>
> >> David
> >> -
> >>
> >>> Note that because of the ifeq comparison, if you use the new
> >>> build
> >>> system and just update the jdk tree, the ifeq
> >>> ($ENABLE_INTREE_EC),
> >>> yes)
> >>> comparison will fail (since ENABLE_INTREE_EC was not previously
> >>> defined)
> >>> and EC will not be part of the build.
> >>>
> >>> This problem wont happen if you update the root repo and re-run
> >>> configure.
> >>>
> >>> On 03/14/2013 06:03 AM, David Holmes wrote:
> On 14/03/2013 3:12 PM, David Holmes wrote:
> > Note that this isn't changing any functionality simply exposing
> > an
> > existing make variable at configure time.
>
> Correction. I misunderstood what was being done here. This
> forcibly
> set/clears the make variable based solely on the existence of a
> directory:
>
> test -d "${SRC_ROOT}/jdk/src/share/native/sun/security/ec/impl"
> >>>
> >>> Yes, it is forcibly set. But since this directory always exists
> >>> in
> >>> OpenJDK 8, this should never evaluate to false.
> >>>
> >>> This change is very useful for distributions, though, since they
> >>> can
> >>> delete the directory when creating a source tarball for OpenJDK8,
> >>> and
> >>> the ECC implementation will be automagically disabled from the
> >>> build.
> >>>
> It doesn't expose a configure option for this. This may be
> perfectly
> fine but the person who wrote the original TODO comment needs to
> verify
> that.
> >>>
> >>> Andrew Hughes wrote the original changeset in the old build
> >>> system
> >>> [1]
> >>> and I believe this is exactly what he wanted out of the
> >>> changeset.
> >>> I am
> >>> CC'ing Erik, who wrote the TODO [2] so he can clarify what he
> >>> meant.
> >>>
> >>> Thanks,
> >>> Omair
> >>>
> >>> [1] http://hg.openjdk.java.net/jdk7/tl/jdk/rev/39c15c0a71f7
> >>> [2]
> >>> http://hg.openjdk.java.net/build-infra/jdk8/jdk/diff/1953cf522107/makefiles/CompileNativeLibraries.gmk
> >>>
> >>
> >
>
--
Andrew :)
Free Java Software Engineer
Red Hat, Inc. (http://www.redhat
Re: Allow configure to detect if EC implementation is present
On 15/03/2013 12:55 PM, Andrew Hughes wrote:
- Original Message -
On 15/03/2013 5:37 AM, Omair Majid wrote:
Hi,
Updated webrev at:
http://cr.openjdk.java.net/~omajid/webrevs/intree-ec/01/
I switched from DISABLE_INTREE_EC to ENABLE_INTREE_EC to avoid the
confusion with double negatives.
Looking just at the mechanics of this it looks fine to me.
I concur.
This needs to
be coordinated with someone from the build team (which isn't me) so
that we can keep the closed generated-configure.sh in sync.
I don't think this is a reasonable requirement generally, though it
may be fine in this case. We should now be getting to the point
where an OpenJDK committer can post a patch, an OpenJDK reviewer
can review it and the committer can push it to an appropriate
repository without either of these people being Oracle employees.
Certainly, the bylaws allow this.
What you're asking here seems no different than me asking for
someone to co-ordinate with the IcedTea team to update their
build machinery. I wouldn't expect this to happen and I don't think
Oracle should either.
We know this is a problem. Hopefully we will have a solution soon that
will alleviate the need for this. In the meantime I would request your
forbearance. I should have said "Can you please ..." rather than "This
needs ...".
Personally I wonder whether the existence check should be in the
Makefile rather than done at configure time? I worry that we end up
with too many make variables becoming configure variables as well.
One of the main functions of a configure script is to make these
variables more easily accessible to the point that you should
only need to set make variables when you need to do a one-time override
of something set by configure. We should no longer be passing a huge
list of make variables.
Totally agreed with the last point.
But to me the division of labor between configure and make is not always
clear.
David
-
I'd argue that Omair's work could be extended, in a further patch, so
that the option was set by --disable-intree-ec and the behaviour
seen here was just the default if the option wasn't specified.
Having configure options also acts as a means of documenting the
various build options (see configure --help), something which
doesn't happen when they are imposed via make.
David
-
Note that because of the ifeq comparison, if you use the new build
system and just update the jdk tree, the ifeq ($ENABLE_INTREE_EC),
yes)
comparison will fail (since ENABLE_INTREE_EC was not previously
defined)
and EC will not be part of the build.
This problem wont happen if you update the root repo and re-run
configure.
On 03/14/2013 06:03 AM, David Holmes wrote:
On 14/03/2013 3:12 PM, David Holmes wrote:
Note that this isn't changing any functionality simply exposing
an
existing make variable at configure time.
Correction. I misunderstood what was being done here. This
forcibly
set/clears the make variable based solely on the existence of a
directory:
test -d "${SRC_ROOT}/jdk/src/share/native/sun/security/ec/impl"
Yes, it is forcibly set. But since this directory always exists in
OpenJDK 8, this should never evaluate to false.
This change is very useful for distributions, though, since they
can
delete the directory when creating a source tarball for OpenJDK8,
and
the ECC implementation will be automagically disabled from the
build.
It doesn't expose a configure option for this. This may be
perfectly
fine but the person who wrote the original TODO comment needs to
verify
that.
Andrew Hughes wrote the original changeset in the old build system
[1]
and I believe this is exactly what he wanted out of the changeset.
I am
CC'ing Erik, who wrote the TODO [2] so he can clarify what he
meant.
Thanks,
Omair
[1] http://hg.openjdk.java.net/jdk7/tl/jdk/rev/39c15c0a71f7
[2]
http://hg.openjdk.java.net/build-infra/jdk8/jdk/diff/1953cf522107/makefiles/CompileNativeLibraries.gmk
Re: Allow configure to detect if EC implementation is present
- Original Message -
> On 15/03/2013 5:37 AM, Omair Majid wrote:
> > Hi,
> >
> > Updated webrev at:
> > http://cr.openjdk.java.net/~omajid/webrevs/intree-ec/01/
> >
> > I switched from DISABLE_INTREE_EC to ENABLE_INTREE_EC to avoid the
> > confusion with double negatives.
>
> Looking just at the mechanics of this it looks fine to me.
I concur.
> This needs
> to
> be coordinated with someone from the build team (which isn't me) so
> that
> we can keep the closed generated-configure.sh in sync.
I don't think this is a reasonable requirement generally, though it
may be fine in this case. We should now be getting to the point
where an OpenJDK committer can post a patch, an OpenJDK reviewer
can review it and the committer can push it to an appropriate
repository without either of these people being Oracle employees.
Certainly, the bylaws allow this.
What you're asking here seems no different than me asking for
someone to co-ordinate with the IcedTea team to update their
build machinery. I wouldn't expect this to happen and I don't think
Oracle should either.
>
> Personally I wonder whether the existence check should be in the
> Makefile rather than done at configure time? I worry that we end up
> with
> too many make variables becoming configure variables as well.
>
One of the main functions of a configure script is to make these
variables more easily accessible to the point that you should
only need to set make variables when you need to do a one-time override
of something set by configure. We should no longer be passing a huge
list of make variables.
I'd argue that Omair's work could be extended, in a further patch, so
that the option was set by --disable-intree-ec and the behaviour
seen here was just the default if the option wasn't specified.
Having configure options also acts as a means of documenting the
various build options (see configure --help), something which
doesn't happen when they are imposed via make.
> David
> -
>
> > Note that because of the ifeq comparison, if you use the new build
> > system and just update the jdk tree, the ifeq ($ENABLE_INTREE_EC),
> > yes)
> > comparison will fail (since ENABLE_INTREE_EC was not previously
> > defined)
> > and EC will not be part of the build.
> >
> > This problem wont happen if you update the root repo and re-run
> > configure.
> >
> > On 03/14/2013 06:03 AM, David Holmes wrote:
> >> On 14/03/2013 3:12 PM, David Holmes wrote:
> >>> Note that this isn't changing any functionality simply exposing
> >>> an
> >>> existing make variable at configure time.
> >>
> >> Correction. I misunderstood what was being done here. This
> >> forcibly
> >> set/clears the make variable based solely on the existence of a
> >> directory:
> >>
> >> test -d "${SRC_ROOT}/jdk/src/share/native/sun/security/ec/impl"
> >
> > Yes, it is forcibly set. But since this directory always exists in
> > OpenJDK 8, this should never evaluate to false.
> >
> > This change is very useful for distributions, though, since they
> > can
> > delete the directory when creating a source tarball for OpenJDK8,
> > and
> > the ECC implementation will be automagically disabled from the
> > build.
> >
> >> It doesn't expose a configure option for this. This may be
> >> perfectly
> >> fine but the person who wrote the original TODO comment needs to
> >> verify
> >> that.
> >
> > Andrew Hughes wrote the original changeset in the old build system
> > [1]
> > and I believe this is exactly what he wanted out of the changeset.
> > I am
> > CC'ing Erik, who wrote the TODO [2] so he can clarify what he
> > meant.
> >
> > Thanks,
> > Omair
> >
> > [1] http://hg.openjdk.java.net/jdk7/tl/jdk/rev/39c15c0a71f7
> > [2]
> > http://hg.openjdk.java.net/build-infra/jdk8/jdk/diff/1953cf522107/makefiles/CompileNativeLibraries.gmk
> >
>
--
Andrew :)
Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)
PGP Key: 248BDC07 (https://keys.indymedia.org/)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07
Re: Allow configure to detect if EC implementation is present
On 15/03/2013 5:37 AM, Omair Majid wrote:
Hi,
Updated webrev at:
http://cr.openjdk.java.net/~omajid/webrevs/intree-ec/01/
I switched from DISABLE_INTREE_EC to ENABLE_INTREE_EC to avoid the
confusion with double negatives.
Looking just at the mechanics of this it looks fine to me. This needs to
be coordinated with someone from the build team (which isn't me) so that
we can keep the closed generated-configure.sh in sync.
Personally I wonder whether the existence check should be in the
Makefile rather than done at configure time? I worry that we end up with
too many make variables becoming configure variables as well.
David
-
Note that because of the ifeq comparison, if you use the new build
system and just update the jdk tree, the ifeq ($ENABLE_INTREE_EC), yes)
comparison will fail (since ENABLE_INTREE_EC was not previously defined)
and EC will not be part of the build.
This problem wont happen if you update the root repo and re-run configure.
On 03/14/2013 06:03 AM, David Holmes wrote:
On 14/03/2013 3:12 PM, David Holmes wrote:
Note that this isn't changing any functionality simply exposing an
existing make variable at configure time.
Correction. I misunderstood what was being done here. This forcibly
set/clears the make variable based solely on the existence of a directory:
test -d "${SRC_ROOT}/jdk/src/share/native/sun/security/ec/impl"
Yes, it is forcibly set. But since this directory always exists in
OpenJDK 8, this should never evaluate to false.
This change is very useful for distributions, though, since they can
delete the directory when creating a source tarball for OpenJDK8, and
the ECC implementation will be automagically disabled from the build.
It doesn't expose a configure option for this. This may be perfectly
fine but the person who wrote the original TODO comment needs to verify
that.
Andrew Hughes wrote the original changeset in the old build system [1]
and I believe this is exactly what he wanted out of the changeset. I am
CC'ing Erik, who wrote the TODO [2] so he can clarify what he meant.
Thanks,
Omair
[1] http://hg.openjdk.java.net/jdk7/tl/jdk/rev/39c15c0a71f7
[2]
http://hg.openjdk.java.net/build-infra/jdk8/jdk/diff/1953cf522107/makefiles/CompileNativeLibraries.gmk
Re: Allow configure to detect if EC implementation is present
On 03/14/2013 03:14 PM, Vincent Ryan wrote: > The DISABLE_INTREE_EC flag is designed to control whether the Elliptic Curve > support in the > JDK source tree is skipped during a build. It is used to avoid the > duplication of EC libraries on > platforms where an EC library is already present. > > In the old build it was a build option. In the new build it appears to be > controlled by the presence > of a directory. That is incorrect as the directory is always present. The > behaviour differs from the old build. FWIW, the current new-build and the current old-build both allow you to specify 'make DISABLE_INTREE_EC=yes' and do the right thing. However, currently there is no way to say this using configure. The patch I posted makes configure automatically set DISABLE_INTREE_EC=yes if the directory is not found. The directory is always present in OpenJDK8. However, some Linux distributions prefer to build with ECC disabled due to legal reasons [1], and will remove the directory when they create the OpenJDK8 source tarball. Where they had to delete the directory _and_ set DISABLE_INTREE_EC before, with this patch they just have to delete the directory. If you would like me to add a configure option to control this as well, then I will be happy to add that too. May I do that as a separate patch? Thanks, Omair [1] http://en.wikipedia.org/wiki/ECC_patents -- PGP Key: 66484681 (http://pgp.mit.edu/) Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681
Re: Allow configure to detect if EC implementation is present
Hi,
Updated webrev at:
http://cr.openjdk.java.net/~omajid/webrevs/intree-ec/01/
I switched from DISABLE_INTREE_EC to ENABLE_INTREE_EC to avoid the
confusion with double negatives.
Note that because of the ifeq comparison, if you use the new build
system and just update the jdk tree, the ifeq ($ENABLE_INTREE_EC), yes)
comparison will fail (since ENABLE_INTREE_EC was not previously defined)
and EC will not be part of the build.
This problem wont happen if you update the root repo and re-run configure.
On 03/14/2013 06:03 AM, David Holmes wrote:
> On 14/03/2013 3:12 PM, David Holmes wrote:
>> Note that this isn't changing any functionality simply exposing an
>> existing make variable at configure time.
>
> Correction. I misunderstood what was being done here. This forcibly
> set/clears the make variable based solely on the existence of a directory:
>
> test -d "${SRC_ROOT}/jdk/src/share/native/sun/security/ec/impl"
Yes, it is forcibly set. But since this directory always exists in
OpenJDK 8, this should never evaluate to false.
This change is very useful for distributions, though, since they can
delete the directory when creating a source tarball for OpenJDK8, and
the ECC implementation will be automagically disabled from the build.
> It doesn't expose a configure option for this. This may be perfectly
> fine but the person who wrote the original TODO comment needs to verify
> that.
Andrew Hughes wrote the original changeset in the old build system [1]
and I believe this is exactly what he wanted out of the changeset. I am
CC'ing Erik, who wrote the TODO [2] so he can clarify what he meant.
Thanks,
Omair
[1] http://hg.openjdk.java.net/jdk7/tl/jdk/rev/39c15c0a71f7
[2]
http://hg.openjdk.java.net/build-infra/jdk8/jdk/diff/1953cf522107/makefiles/CompileNativeLibraries.gmk
--
PGP Key: 66484681 (http://pgp.mit.edu/)
Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681
Re: Allow configure to detect if EC implementation is present
The DISABLE_INTREE_EC flag is designed to control whether the Elliptic Curve
support in the
JDK source tree is skipped during a build. It is used to avoid the duplication
of EC libraries on
platforms where an EC library is already present.
In the old build it was a build option. In the new build it appears to be
controlled by the presence
of a directory. That is incorrect as the directory is always present. The
behaviour differs from the old build.
On 14 Mar 2013, at 10:03, David Holmes wrote:
> On 14/03/2013 3:12 PM, David Holmes wrote:
>> Note that this isn't changing any functionality simply exposing an
>> existing make variable at configure time.
>
> Correction. I misunderstood what was being done here. This forcibly
> set/clears the make variable based solely on the existence of a directory:
>
> test -d "${SRC_ROOT}/jdk/src/share/native/sun/security/ec/impl"
>
> It doesn't expose a configure option for this. This may be perfectly fine but
> the person who wrote the original TODO comment needs to verify that.
>
> David
>
>> David
>>
>> On 14/03/2013 2:38 PM, Brad Wetmore wrote:
>>> CC'ing security-dev.
>>>
>>> Vinnie,
>>>
>>> As owner of ECC, you should probably look at this.
>>>
>>> Brad
>>>
>>>
>>> On 3/13/2013 7:02 PM, David Holmes wrote:
On 14/03/2013 6:09 AM, Omair Majid wrote:
> Hi,
>
> jdk/makefiles/CompileNativeLibraries.gmk has a little note:
>
> TODO Set DISABLE_INTREE_EC in configure if
> src/share/native/sun/security/ec/impl is not present
>
> The webrev at http://cr.openjdk.java.net/~omajid/webrevs/intree-ec/00/
> implements this. Does this look okay for jdk8/build ? Can I get a bug
> id?
Bug ID: 8010030
I think it is more consistent to set the variable to yes/no and change:
ifndef DISABLE_INTREE_EC
to
ifeq ($DISABLE_INTREE_EC), yes)
Thanks,
David
> Thanks,
> Omair
>
Re: Allow configure to detect if EC implementation is present
On 14/03/2013 3:12 PM, David Holmes wrote:
Note that this isn't changing any functionality simply exposing an
existing make variable at configure time.
Correction. I misunderstood what was being done here. This forcibly
set/clears the make variable based solely on the existence of a directory:
test -d "${SRC_ROOT}/jdk/src/share/native/sun/security/ec/impl"
It doesn't expose a configure option for this. This may be perfectly
fine but the person who wrote the original TODO comment needs to verify
that.
David
David
On 14/03/2013 2:38 PM, Brad Wetmore wrote:
CC'ing security-dev.
Vinnie,
As owner of ECC, you should probably look at this.
Brad
On 3/13/2013 7:02 PM, David Holmes wrote:
On 14/03/2013 6:09 AM, Omair Majid wrote:
Hi,
jdk/makefiles/CompileNativeLibraries.gmk has a little note:
TODO Set DISABLE_INTREE_EC in configure if
src/share/native/sun/security/ec/impl is not present
The webrev at http://cr.openjdk.java.net/~omajid/webrevs/intree-ec/00/
implements this. Does this look okay for jdk8/build ? Can I get a bug
id?
Bug ID: 8010030
I think it is more consistent to set the variable to yes/no and change:
ifndef DISABLE_INTREE_EC
to
ifeq ($DISABLE_INTREE_EC), yes)
Thanks,
David
Thanks,
Omair
Re: Allow configure to detect if EC implementation is present
Note that this isn't changing any functionality simply exposing an existing make variable at configure time. David On 14/03/2013 2:38 PM, Brad Wetmore wrote: CC'ing security-dev. Vinnie, As owner of ECC, you should probably look at this. Brad On 3/13/2013 7:02 PM, David Holmes wrote: On 14/03/2013 6:09 AM, Omair Majid wrote: Hi, jdk/makefiles/CompileNativeLibraries.gmk has a little note: TODO Set DISABLE_INTREE_EC in configure if src/share/native/sun/security/ec/impl is not present The webrev at http://cr.openjdk.java.net/~omajid/webrevs/intree-ec/00/ implements this. Does this look okay for jdk8/build ? Can I get a bug id? Bug ID: 8010030 I think it is more consistent to set the variable to yes/no and change: ifndef DISABLE_INTREE_EC to ifeq ($DISABLE_INTREE_EC), yes) Thanks, David Thanks, Omair
Re: Allow configure to detect if EC implementation is present
CC'ing security-dev. Vinnie, As owner of ECC, you should probably look at this. Brad On 3/13/2013 7:02 PM, David Holmes wrote: On 14/03/2013 6:09 AM, Omair Majid wrote: Hi, jdk/makefiles/CompileNativeLibraries.gmk has a little note: TODO Set DISABLE_INTREE_EC in configure if src/share/native/sun/security/ec/impl is not present The webrev at http://cr.openjdk.java.net/~omajid/webrevs/intree-ec/00/ implements this. Does this look okay for jdk8/build ? Can I get a bug id? Bug ID: 8010030 I think it is more consistent to set the variable to yes/no and change: ifndef DISABLE_INTREE_EC to ifeq ($DISABLE_INTREE_EC), yes) Thanks, David Thanks, Omair
