Re: macOS High Sierra, version 10.13.2 configure: error: Could not find freetype! You might be able to fix this by running 'brew install freetype'

[Erik Joelsson]

Hello,

I just tried this myself and configure is automatically picking up my 
freetype from brew in /usr/local/opt/freetype/. Looking at my log, this 
is done using pkg-config from brew. So you could try installing 
pkg-config (brew install pkg-config). You can also try adding 
--with-freetype=/usr/local/opt/freetype if that's where brew installed 
it for you.


/Erik


On 2018-02-11 22:51, mbl wrote:

OS: macOS High Sierra, version 10.13.2
Repo : https://github.com/dmlloyd/openjdk.git
Branch : jdk/jdk

mbldeMacBook-Pro:openjdk mbl$ bash ./configure 
--with-boot-jdk=/Library/Java/JavaVirtualMachines/jdk9.0.4.jdk/Home
configure: Configuration created at Mon Feb 12 14:43:36 CST 2018.
configure: error: Could not find freetype! You might be able to fix this by 
running 'brew install freetype'.
/projects/jdpros/openjdk/.build/generated-configure.sh: line 82: 5: Bad file 
descriptor
configure exiting with result code 1
mbldeMacBook-Pro:openjdk mbl$ sudo brew install freetype
Password:
Error: Running Homebrew as root is extremely dangerous and no longer supported.
As Homebrew does not drop privileges on installation you would be giving all
build scripts full access to your system.
mbldeMacBook-Pro:openjdk mbl$ brew install freetype
Updating Homebrew...
Warning: freetype 2.9 is already installed


What can I do?

macOS High Sierra, version 10.13.2 configure: error: Could not find freetype! You might be able to fix this by running 'brew install freetype'

[mbl]

OS: macOS High Sierra, version 10.13.2
Repo : https://github.com/dmlloyd/openjdk.git
Branch : jdk/jdk

mbldeMacBook-Pro:openjdk mbl$ bash ./configure 
--with-boot-jdk=/Library/Java/JavaVirtualMachines/jdk9.0.4.jdk/Home
configure: Configuration created at Mon Feb 12 14:43:36 CST 2018.
configure: error: Could not find freetype! You might be able to fix this by 
running 'brew install freetype'.
/projects/jdpros/openjdk/.build/generated-configure.sh: line 82: 5: Bad file 
descriptor
configure exiting with result code 1
mbldeMacBook-Pro:openjdk mbl$ sudo brew install freetype
Password:
Error: Running Homebrew as root is extremely dangerous and no longer supported.
As Homebrew does not drop privileges on installation you would be giving all
build scripts full access to your system.
mbldeMacBook-Pro:openjdk mbl$ brew install freetype
Updating Homebrew...
Warning: freetype 2.9 is already installed


What can I do?

Re: RFR [xxs, aix]: JDK-8196488: [aix] TOC overflow for libjvm.so in fastdebug build

[Thomas Stüfe]

On Mon, Feb 12, 2018 at 4:41 PM, Magnus Ihse Bursie <
magnus.ihse.bur...@oracle.com> wrote:

> On 2018-02-12 15:32, Thomas Stüfe wrote:
>
>> Hi all,
>>
>> may I have a sponsor please? I am not sure whether I am allowed to push
>> myself, and if yes, to which repository.
>>
>
> Since the removal of generated-configure.sh you don't need a sponsor just
> because you touch autoconf files. So for jdk/jdk, you're free to just push
> it. As far as I understand, you're also free to just push it to jdk/hs
> nowadays, if that were you want it to go, but someone from hotspot should
> probably confirm this.
>
>
Ok. Nice to know. Thanks.

..Thomas


> /Magnus
>
>
>
>> I have three reviewers already.
>>
>> Thank you!
>>
>> Thomas
>>
>>
>> On Thu, Feb 8, 2018 at 3:42 PM, Thomas Stüfe 
>> wrote:
>>
>> Hi,
>>>
>>> may I please have reviews for this tiny fix:
>>>
>>> Bug:  https://bugs.openjdk.java.net/browse/JDK-8196488
>>> webrev: http://cr.openjdk.java.net/~stuefe/webrevs/
>>> 8196488-aix-toc-overflow-in-fastdebug/webrev.00/webrev/
>>>
>>> Thanks and Kind Regards, Thomas
>>>
>>>
>

Re: RFR: JDK-8197571 Change storage location for generated-configure.sh

[Thomas Stüfe]

On Mon, Feb 12, 2018 at 4:38 PM, Magnus Ihse Bursie <
magnus.ihse.bur...@oracle.com> wrote:

>
> On 2018-02-12 14:57, Thomas Stüfe wrote:
>
>
>
> On Mon, Feb 12, 2018 at 2:53 PM, Magnus Ihse Bursie <
> magnus.ihse.bur...@oracle.com> wrote:
>
>> On 2018-02-12 14:47, Thomas Stüfe wrote:
>>
>> Hi Magnus,
>>
>> Thanks a lot for fixing this! I tried my configuration as described in
>> earlier mails, and the configure scripts gets now created in the output
>> directory as expected.
>>
>> Some notes:
>>
>> - would it be possible to write out the path name of the generated
>> configure shell script?
>>
>> Sure, but why? What's the use case? Do you want it only when it is
>> generated/updated, or always when running configure?
>>
>>
> The former. Just as an information.
>
> Ok, I updated the printout to look like this:
> Runnable configure script is not present
> Generating runnable configure script at /localhome/hg/jdk-ALT/open/
> build/.configure-support/generated-configure.sh
> Using autoconf at /usr/local/bin/autoconf [autoconf (GNU Autoconf) 2.69]
> ...
>
> I didn't think this warranted a re-review.
>
>
Sure. Thank you.

..Thomas


> /Magnus
>
>
>
>> - No concern of mine, because I never do this, but just something I noted
>> when looking at the change: it seems before the patch it was possible to
>> start the make from any subdirectory within the source tree and still have
>> the build configuration written to source tree root. That would not work
>> anymore, now builds inside the source tree have to be started from the root
>> of the source tree?
>>
>>
>> We have never supported running configure in anything but an empty
>> director or the source tree root. You will end up with something like:
>>
>> configure: Current directory is /localhome/hg/jdk-ALT/open/src.
>> configure: Since this is not the source root, configure will output the
>> configuration here
>> configure: (as opposed to creating a configuration in
>> /build/).
>> configure: However, this directory is not empty. This is not allowed,
>> since it could
>> configure: seriously mess up just about everything.
>>
>>
> Okay. Change is reviewed from my end.
>
> Thanks, Thomas
>
>
>> /Magnus
>>
>>
>>
>> Kind Regards, Thomas
>>
>>
>> On Mon, Feb 12, 2018 at 2:09 PM, Magnus Ihse Bursie <
>> magnus.ihse.bur...@oracle.com> wrote:
>>
>>> In JDK-8195689, the generated-configure.sh was no longer checked in, but
>>> locally generated. The selected location for generation ($TOPDIR/.build)
>>> was not unproblematic for some use cases. This patch attempts remedy this.
>>>
>>> The new behaviour will be this:
>>>  * If run from $TOPDIR, the storage directory will be
>>> $TOPDIR/build/.configure-support.
>>>  * If run from $CUSTOM_ROOT, the storage directory will be
>>> $CUSTOM_ROOT/build/.configure-support.
>>>  * If run from any other directory (about to become the build output
>>> directory for the configuration), the storage directory will be
>>> $PWD/configure-support.
>>>
>>> This will allow "rm -rf $TOPDIR/build" to function as before to remove
>>> all build artifacts. It will allow configuration created in out-of-tree
>>> directories to have the script generated locally.
>>>
>>> I could not put the output file in build/$BUILD/configure-support,
>>> since the $BUILD name is not yet determined. I did not want to put it in
>>> build/configure-support, since that would make it look like a configuration
>>> to the code that enumerates configurations in build.
>>>
>>> I hope this addresses all issues that has been raised.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8197571
>>> WebRev: http://cr.openjdk.java.net/~ihse/JDK-8197571-change-storage-
>>> location-for-generated-configure/webrev.01
>>>
>>> /Magnus
>>>
>>>
>>
>>
>
>

Re: RFR: JDK-8197571 Change storage location for generated-configure.sh

[Magnus Ihse Bursie]

On 2018-02-12 14:57, Thomas Stüfe wrote:



On Mon, Feb 12, 2018 at 2:53 PM, Magnus Ihse Bursie 
> 
wrote:


On 2018-02-12 14:47, Thomas Stüfe wrote:

Hi Magnus,

Thanks a lot for fixing this! I tried my configuration as
described in earlier mails, and the configure scripts gets now
created in the output directory as expected.

Some notes:

- would it be possible to write out the path name of the
generated configure shell script?

Sure, but why? What's the use case? Do you want it only when it is
generated/updated, or always when running configure?


The former. Just as an information.

Ok, I updated the printout to look like this:
Runnable configure script is not present
Generating runnable configure script at 
/localhome/hg/jdk-ALT/open/build/.configure-support/generated-configure.sh

Using autoconf at /usr/local/bin/autoconf [autoconf (GNU Autoconf) 2.69]
...

I didn't think this warranted a re-review.

/Magnus


- No concern of mine, because I never do this, but just something
I noted when looking at the change: it seems before the patch it
was possible to start the make from any subdirectory within the
source tree and still have the build configuration written to
source tree root. That would not work anymore, now builds inside
the source tree have to be started from the root of the source tree?


We have never supported running configure in anything but an empty
director or the source tree root. You will end up with something like:

configure: Current directory is /localhome/hg/jdk-ALT/open/src.
configure: Since this is not the source root, configure will
output the configuration here
configure: (as opposed to creating a configuration in
/build/).
configure: However, this directory is not empty. This is not
allowed, since it could
configure: seriously mess up just about everything.


Okay. Change is reviewed from my end.

Thanks, Thomas

/Magnus




Kind Regards, Thomas


On Mon, Feb 12, 2018 at 2:09 PM, Magnus Ihse Bursie
> wrote:

In JDK-8195689, the generated-configure.sh was no longer
checked in, but locally generated. The selected location for
generation ($TOPDIR/.build) was not unproblematic for some
use cases. This patch attempts remedy this.

The new behaviour will be this:
 * If run from $TOPDIR, the storage directory will be
$TOPDIR/build/.configure-support.
 * If run from $CUSTOM_ROOT, the storage directory will be
$CUSTOM_ROOT/build/.configure-support.
 * If run from any other directory (about to become the build
output directory for the configuration), the storage
directory will be $PWD/configure-support.

This will allow "rm -rf $TOPDIR/build" to function as before
to remove all build artifacts. It will allow configuration
created in out-of-tree directories to have the script
generated locally.

I could not put the output file in
build/$BUILD/configure-support, since the $BUILD name is not
yet determined. I did not want to put it in
build/configure-support, since that would make it look like a
configuration to the code that enumerates configurations in
build.

I hope this addresses all issues that has been raised.

Bug: https://bugs.openjdk.java.net/browse/JDK-8197571

WebRev:

http://cr.openjdk.java.net/~ihse/JDK-8197571-change-storage-location-for-generated-configure/webrev.01



/Magnus

Re: RFR [xxs, aix]: JDK-8196488: [aix] TOC overflow for libjvm.so in fastdebug build

[Magnus Ihse Bursie]

On 2018-02-12 15:32, Thomas Stüfe wrote:

Hi all,

may I have a sponsor please? I am not sure whether I am allowed to push
myself, and if yes, to which repository.


Since the removal of generated-configure.sh you don't need a sponsor 
just because you touch autoconf files. So for jdk/jdk, you're free to 
just push it. As far as I understand, you're also free to just push it 
to jdk/hs nowadays, if that were you want it to go, but someone from 
hotspot should probably confirm this.


/Magnus



I have three reviewers already.

Thank you!

Thomas


On Thu, Feb 8, 2018 at 3:42 PM, Thomas Stüfe 
wrote:


Hi,

may I please have reviews for this tiny fix:

Bug:  https://bugs.openjdk.java.net/browse/JDK-8196488
webrev: http://cr.openjdk.java.net/~stuefe/webrevs/
8196488-aix-toc-overflow-in-fastdebug/webrev.00/webrev/

Thanks and Kind Regards, Thomas

Re: RFR: JDK-8197571 Change storage location for generated-configure.sh

[Tim Bell]

Magnus:

Looks good to me as well.

/Tim

On 02/12/18 06:31, Volker Simonis wrote:

Hi Magnus,

thanks for doing this change. It was actually on my TODO list but I
somehow forgot about it :)

The change looks good. Thumb up from me,
Volker

On Mon, Feb 12, 2018 at 2:09 PM, Magnus Ihse Bursie
 wrote:

In JDK-8195689, the generated-configure.sh was no longer checked in, but
locally generated. The selected location for generation ($TOPDIR/.build) was
not unproblematic for some use cases. This patch attempts remedy this.

The new behaviour will be this:
  * If run from $TOPDIR, the storage directory will be
$TOPDIR/build/.configure-support.
  * If run from $CUSTOM_ROOT, the storage directory will be
$CUSTOM_ROOT/build/.configure-support.
  * If run from any other directory (about to become the build output
directory for the configuration), the storage directory will be
$PWD/configure-support.

This will allow "rm -rf $TOPDIR/build" to function as before to remove all
build artifacts. It will allow configuration created in out-of-tree
directories to have the script generated locally.

I could not put the output file in build/$BUILD/configure-support, since the
$BUILD name is not yet determined. I did not want to put it in
build/configure-support, since that would make it look like a configuration
to the code that enumerates configurations in build.

I hope this addresses all issues that has been raised.

Bug: https://bugs.openjdk.java.net/browse/JDK-8197571
WebRev:
http://cr.openjdk.java.net/~ihse/JDK-8197571-change-storage-location-for-generated-configure/webrev.01

/Magnus

Re: RFR [xxs, aix]: JDK-8196488: [aix] TOC overflow for libjvm.so in fastdebug build

[Thomas Stüfe]

Please disregard my last mail, the change has just been pushed.

Thanks, Thomas

On Mon, Feb 12, 2018 at 3:32 PM, Thomas Stüfe 
wrote:

> Hi all,
>
> may I have a sponsor please? I am not sure whether I am allowed to push
> myself, and if yes, to which repository.
>
> I have three reviewers already.
>
> Thank you!
>
> Thomas
>
>
> On Thu, Feb 8, 2018 at 3:42 PM, Thomas Stüfe 
> wrote:
>
>> Hi,
>>
>> may I please have reviews for this tiny fix:
>>
>> Bug:  https://bugs.openjdk.java.net/browse/JDK-8196488
>> webrev: http://cr.openjdk.java.net/~stuefe/webrevs/8196488-
>> aix-toc-overflow-in-fastdebug/webrev.00/webrev/
>>
>> Thanks and Kind Regards, Thomas
>>
>
>

Re: RFR [xxs, aix]: JDK-8196488: [aix] TOC overflow for libjvm.so in fastdebug build

[Thomas Stüfe]

Hi all,

may I have a sponsor please? I am not sure whether I am allowed to push
myself, and if yes, to which repository.

I have three reviewers already.

Thank you!

Thomas


On Thu, Feb 8, 2018 at 3:42 PM, Thomas Stüfe 
wrote:

> Hi,
>
> may I please have reviews for this tiny fix:
>
> Bug:  https://bugs.openjdk.java.net/browse/JDK-8196488
> webrev: http://cr.openjdk.java.net/~stuefe/webrevs/
> 8196488-aix-toc-overflow-in-fastdebug/webrev.00/webrev/
>
> Thanks and Kind Regards, Thomas
>

Re: RFR: JDK-8197571 Change storage location for generated-configure.sh

[Volker Simonis]

Hi Magnus,

thanks for doing this change. It was actually on my TODO list but I
somehow forgot about it :)

The change looks good. Thumb up from me,
Volker

On Mon, Feb 12, 2018 at 2:09 PM, Magnus Ihse Bursie
 wrote:
> In JDK-8195689, the generated-configure.sh was no longer checked in, but
> locally generated. The selected location for generation ($TOPDIR/.build) was
> not unproblematic for some use cases. This patch attempts remedy this.
>
> The new behaviour will be this:
>  * If run from $TOPDIR, the storage directory will be
> $TOPDIR/build/.configure-support.
>  * If run from $CUSTOM_ROOT, the storage directory will be
> $CUSTOM_ROOT/build/.configure-support.
>  * If run from any other directory (about to become the build output
> directory for the configuration), the storage directory will be
> $PWD/configure-support.
>
> This will allow "rm -rf $TOPDIR/build" to function as before to remove all
> build artifacts. It will allow configuration created in out-of-tree
> directories to have the script generated locally.
>
> I could not put the output file in build/$BUILD/configure-support, since the
> $BUILD name is not yet determined. I did not want to put it in
> build/configure-support, since that would make it look like a configuration
> to the code that enumerates configurations in build.
>
> I hope this addresses all issues that has been raised.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8197571
> WebRev:
> http://cr.openjdk.java.net/~ihse/JDK-8197571-change-storage-location-for-generated-configure/webrev.01
>
> /Magnus
>

Re: RFR: JDK-8196356: Changes to m4 files don't trigger autoconf execution at build time

[Magnus Ihse Bursie]

On 2018-02-10 12:29, Thomas Stüfe wrote:

On Sat, Feb 10, 2018 at 9:12 AM, Alan Bateman 
wrote:


On 08/02/2018 17:49, Erik Joelsson wrote:


The check for when to generate the generated configure script is not
working quite as expected. It currently only compares timestamps if the
local repository has any local changes in the make/autoconf directory. This
used to make sense when we had a committed generated script, but now we
actually do need to regenerate any time an input file is newer than the
generated script.

Bug: https://bugs.openjdk.java.net/browse/JDK-8196356


In addition to `hg status` showing no changes, I think it will continue to
confuse people to generate it into a hidden directory. Was there any
consideration to generating into a regular directory?



I agree. Also, we still generate the configure.sh into the source tree even
if the output directory is somewhere else. I always keep my output
directories separate from the source tree. Sometimes my source directory is
even on a read-only share. I would prefer and also expect any temporary
files to be placed in the output directory resp. the current directory, not
in the source tree. Would that be possible?
As discussed in another thread, the current behaviour is no good when 
running configure outside the source tree root. We should definitely fix 
that (I thought Volker were going to publish a RFR but that didn't 
happen; I'll pick up the ball and submit a RFR). With that in place, the 
behaviour will in principle be that the output is in the current directory.


/Magnus




Thanks and Kind Regards, Thomas



-Alan

Re: RFR: JDK-8197571 Change storage location for generated-configure.sh

[Thomas Stüfe]

On Mon, Feb 12, 2018 at 2:53 PM, Magnus Ihse Bursie <
magnus.ihse.bur...@oracle.com> wrote:

> On 2018-02-12 14:47, Thomas Stüfe wrote:
>
> Hi Magnus,
>
> Thanks a lot for fixing this! I tried my configuration as described in
> earlier mails, and the configure scripts gets now created in the output
> directory as expected.
>
> Some notes:
>
> - would it be possible to write out the path name of the generated
> configure shell script?
>
> Sure, but why? What's the use case? Do you want it only when it is
> generated/updated, or always when running configure?
>
>
The former. Just as an information.


> - No concern of mine, because I never do this, but just something I noted
> when looking at the change: it seems before the patch it was possible to
> start the make from any subdirectory within the source tree and still have
> the build configuration written to source tree root. That would not work
> anymore, now builds inside the source tree have to be started from the root
> of the source tree?
>
>
> We have never supported running configure in anything but an empty
> director or the source tree root. You will end up with something like:
>
> configure: Current directory is /localhome/hg/jdk-ALT/open/src.
> configure: Since this is not the source root, configure will output the
> configuration here
> configure: (as opposed to creating a configuration in
> /build/).
> configure: However, this directory is not empty. This is not allowed,
> since it could
> configure: seriously mess up just about everything.
>
>
Okay. Change is reviewed from my end.

Thanks, Thomas


> /Magnus
>
>
>
> Kind Regards, Thomas
>
>
> On Mon, Feb 12, 2018 at 2:09 PM, Magnus Ihse Bursie <
> magnus.ihse.bur...@oracle.com> wrote:
>
>> In JDK-8195689, the generated-configure.sh was no longer checked in, but
>> locally generated. The selected location for generation ($TOPDIR/.build)
>> was not unproblematic for some use cases. This patch attempts remedy this.
>>
>> The new behaviour will be this:
>>  * If run from $TOPDIR, the storage directory will be
>> $TOPDIR/build/.configure-support.
>>  * If run from $CUSTOM_ROOT, the storage directory will be
>> $CUSTOM_ROOT/build/.configure-support.
>>  * If run from any other directory (about to become the build output
>> directory for the configuration), the storage directory will be
>> $PWD/configure-support.
>>
>> This will allow "rm -rf $TOPDIR/build" to function as before to remove
>> all build artifacts. It will allow configuration created in out-of-tree
>> directories to have the script generated locally.
>>
>> I could not put the output file in build/$BUILD/configure-support, since
>> the $BUILD name is not yet determined. I did not want to put it in
>> build/configure-support, since that would make it look like a configuration
>> to the code that enumerates configurations in build.
>>
>> I hope this addresses all issues that has been raised.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8197571
>> WebRev: http://cr.openjdk.java.net/~ihse/JDK-8197571-change-storage-
>> location-for-generated-configure/webrev.01
>>
>> /Magnus
>>
>>
>
>

Re: RFR: JDK-8197571 Change storage location for generated-configure.sh

[Magnus Ihse Bursie]

On 2018-02-12 14:47, Thomas Stüfe wrote:

Hi Magnus,

Thanks a lot for fixing this! I tried my configuration as described in 
earlier mails, and the configure scripts gets now created in the 
output directory as expected.


Some notes:

- would it be possible to write out the path name of the generated 
configure shell script?
Sure, but why? What's the use case? Do you want it only when it is 
generated/updated, or always when running configure?


- No concern of mine, because I never do this, but just something I 
noted when looking at the change: it seems before the patch it was 
possible to start the make from any subdirectory within the source 
tree and still have the build configuration written to source tree 
root. That would not work anymore, now builds inside the source tree 
have to be started from the root of the source tree?


We have never supported running configure in anything but an empty 
director or the source tree root. You will end up with something like:


configure: Current directory is /localhome/hg/jdk-ALT/open/src.
configure: Since this is not the source root, configure will output the 
configuration here
configure: (as opposed to creating a configuration in 
/build/).
configure: However, this directory is not empty. This is not allowed, 
since it could

configure: seriously mess up just about everything.

/Magnus




Kind Regards, Thomas


On Mon, Feb 12, 2018 at 2:09 PM, Magnus Ihse Bursie 
> 
wrote:


In JDK-8195689, the generated-configure.sh was no longer checked
in, but locally generated. The selected location for generation
($TOPDIR/.build) was not unproblematic for some use cases. This
patch attempts remedy this.

The new behaviour will be this:
 * If run from $TOPDIR, the storage directory will be
$TOPDIR/build/.configure-support.
 * If run from $CUSTOM_ROOT, the storage directory will be
$CUSTOM_ROOT/build/.configure-support.
 * If run from any other directory (about to become the build
output directory for the configuration), the storage directory
will be $PWD/configure-support.

This will allow "rm -rf $TOPDIR/build" to function as before to
remove all build artifacts. It will allow configuration created in
out-of-tree directories to have the script generated locally.

I could not put the output file in build/$BUILD/configure-support,
since the $BUILD name is not yet determined. I did not want to put
it in build/configure-support, since that would make it look like
a configuration to the code that enumerates configurations in build.

I hope this addresses all issues that has been raised.

Bug: https://bugs.openjdk.java.net/browse/JDK-8197571

WebRev:

http://cr.openjdk.java.net/~ihse/JDK-8197571-change-storage-location-for-generated-configure/webrev.01



/Magnus

Re: RFR: JDK-8197571 Change storage location for generated-configure.sh

[Thomas Stüfe]

Hi Magnus,

Thanks a lot for fixing this! I tried my configuration as described in
earlier mails, and the configure scripts gets now created in the output
directory as expected.

Some notes:

- would it be possible to write out the path name of the generated
configure shell script?
- No concern of mine, because I never do this, but just something I noted
when looking at the change: it seems before the patch it was possible to
start the make from any subdirectory within the source tree and still have
the build configuration written to source tree root. That would not work
anymore, now builds inside the source tree have to be started from the root
of the source tree?

Kind Regards, Thomas


On Mon, Feb 12, 2018 at 2:09 PM, Magnus Ihse Bursie <
magnus.ihse.bur...@oracle.com> wrote:

> In JDK-8195689, the generated-configure.sh was no longer checked in, but
> locally generated. The selected location for generation ($TOPDIR/.build)
> was not unproblematic for some use cases. This patch attempts remedy this.
>
> The new behaviour will be this:
>  * If run from $TOPDIR, the storage directory will be
> $TOPDIR/build/.configure-support.
>  * If run from $CUSTOM_ROOT, the storage directory will be
> $CUSTOM_ROOT/build/.configure-support.
>  * If run from any other directory (about to become the build output
> directory for the configuration), the storage directory will be
> $PWD/configure-support.
>
> This will allow "rm -rf $TOPDIR/build" to function as before to remove all
> build artifacts. It will allow configuration created in out-of-tree
> directories to have the script generated locally.
>
> I could not put the output file in build/$BUILD/configure-support, since
> the $BUILD name is not yet determined. I did not want to put it in
> build/configure-support, since that would make it look like a configuration
> to the code that enumerates configurations in build.
>
> I hope this addresses all issues that has been raised.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8197571
> WebRev: http://cr.openjdk.java.net/~ihse/JDK-8197571-change-storage-
> location-for-generated-configure/webrev.01
>
> /Magnus
>
>

RFR: JDK-8197571 Change storage location for generated-configure.sh

[Magnus Ihse Bursie]

In JDK-8195689, the generated-configure.sh was no longer checked in, but 
locally generated. The selected location for generation ($TOPDIR/.build) 
was not unproblematic for some use cases. This patch attempts remedy this.


The new behaviour will be this:
 * If run from $TOPDIR, the storage directory will be 
$TOPDIR/build/.configure-support.
 * If run from $CUSTOM_ROOT, the storage directory will be 
$CUSTOM_ROOT/build/.configure-support.
 * If run from any other directory (about to become the build output 
directory for the configuration), the storage directory will be 
$PWD/configure-support.


This will allow "rm -rf $TOPDIR/build" to function as before to remove 
all build artifacts. It will allow configuration created in out-of-tree 
directories to have the script generated locally.


I could not put the output file in build/$BUILD/configure-support, since 
the $BUILD name is not yet determined. I did not want to put it in 
build/configure-support, since that would make it look like a 
configuration to the code that enumerates configurations in build.


I hope this addresses all issues that has been raised.

Bug: https://bugs.openjdk.java.net/browse/JDK-8197571
WebRev: 
http://cr.openjdk.java.net/~ihse/JDK-8197571-change-storage-location-for-generated-configure/webrev.01


/Magnus

Re: RFR: JDK-8196356: Changes to m4 files don't trigger autoconf execution at build time

[Thomas Stüfe]

Hi Magnus,

On Mon, Feb 12, 2018 at 12:50 PM, Magnus Ihse Bursie <
magnus.ihse.bur...@oracle.com> wrote:

> On 2018-02-10 23:39, Martin Buchholz wrote:
>
>> I agree.  Once you make something lazy-initted you have a concurrency
>> problem.  And there's no CAS or lock on the filesystem.  What happens if
>> two configure processes run at exactly the same time, perhaps even with
>> different versions of autoconf?  If you lazy-generate configure, it must
>> be
>> written outside the source tree.
>>
> That is of course a problem with the entire build system, and is certainly
> not unique to this problem. What happens if you run "make" concurrently in
> the same directory? Catastrophe! Or if you run "configure" at the same
> time? Disaster! Creating the file outside the source tree will not help in
> the slightest regard; you can just as well create a race condition in any
> place you select. This does not sound like a real-world problem that one
> has to safe-guard against.
>
>
Until now it was perfectly fine to run N makes in parallel from the same
source tree. I do this all the time: I have a source directory and a number
of output directories side by side for various build configurations (debug,
fastdebug, release, 32bit, zero...); in the morning I pull all changes and
start a number of scratch builds. We also do this nightly. We share source
trees for multiple builds (among other reasons it makes comparing builds
easier).

But since now the configuration is written by the build into the source
tree, parallel builds can overwrite each others generated-configure shell
script.

As for your other mail, this issue here (generating stuff into the source
tree) is for me a far greater pain than the fact that the directory is
hidden; the latter is just aesthetics, and as you say, we already do this
in other cases.

Best Regards, Thomas




> /Magnus
>
>
>
>> On Sat, Feb 10, 2018 at 3:29 AM, Thomas Stüfe 
>> wrote:
>>
>> On Sat, Feb 10, 2018 at 9:12 AM, Alan Bateman 
>>> wrote:
>>>
>>> On 08/02/2018 17:49, Erik Joelsson wrote:

 The check for when to generate the generated configure script is not
> working quite as expected. It currently only compares timestamps if the
> local repository has any local changes in the make/autoconf directory.
>
 This
>>>
 used to make sense when we had a committed generated script, but now we
> actually do need to regenerate any time an input file is newer than the
> generated script.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8196356
>
> In addition to `hg status` showing no changes, I think it will continue

>>> to
>>>
 confuse people to generate it into a hidden directory. Was there any
 consideration to generating into a regular directory?


 I agree. Also, we still generate the configure.sh into the source tree
>>> even
>>> if the output directory is somewhere else. I always keep my output
>>> directories separate from the source tree. Sometimes my source directory
>>> is
>>> even on a read-only share. I would prefer and also expect any temporary
>>> files to be placed in the output directory resp. the current directory,
>>> not
>>> in the source tree. Would that be possible?
>>>
>>> Thanks and Kind Regards, Thomas
>>>
>>>
>>> -Alan


>

Re: RFR: JDK-8196356: Changes to m4 files don't trigger autoconf execution at build time

[Alan Bateman]

On 12/02/2018 11:42, Magnus Ihse Bursie wrote:


Why would hidden files be confusing? Or, rephrased, how is this any 
more confusing than other hidden directories, such as .idea or .jib? I 
modelled the behaviour on jib. In fact, I was considering using the 
same directory (.jib), but since the name was so specialized, it felt 
like misusing it. That's why I gave it a more general name. (In fact, 
I believe, if .build had been present when jib was created, it would 
have used that instead of creating the specialized .jib directory).
I'm aware of at least 10 people that ran into problems in the latter 
part of last week because they didn't know about the .build directory. I 
think most people are used to blowing away the build directory, the 
.build directory is new so we need to learn to blow away that too 
(irrespective of whether the build re-generated when it seems the time 
stamp is old). All I'm saying is that hidden directories have a tenancy 
to confuse. I can't comment on .jib as that is not in OpenJDK.


-Alan

Re: RFR: JDK-8196356: Changes to m4 files don't trigger autoconf execution at build time

[Magnus Ihse Bursie]

On 2018-02-10 23:39, Martin Buchholz wrote:

I agree.  Once you make something lazy-initted you have a concurrency
problem.  And there's no CAS or lock on the filesystem.  What happens if
two configure processes run at exactly the same time, perhaps even with
different versions of autoconf?  If you lazy-generate configure, it must be
written outside the source tree.
That is of course a problem with the entire build system, and is 
certainly not unique to this problem. What happens if you run "make" 
concurrently in the same directory? Catastrophe! Or if you run 
"configure" at the same time? Disaster! Creating the file outside the 
source tree will not help in the slightest regard; you can just as well 
create a race condition in any place you select. This does not sound 
like a real-world problem that one has to safe-guard against.


/Magnus



On Sat, Feb 10, 2018 at 3:29 AM, Thomas Stüfe 
wrote:


On Sat, Feb 10, 2018 at 9:12 AM, Alan Bateman 
wrote:


On 08/02/2018 17:49, Erik Joelsson wrote:


The check for when to generate the generated configure script is not
working quite as expected. It currently only compares timestamps if the
local repository has any local changes in the make/autoconf directory.

This

used to make sense when we had a committed generated script, but now we
actually do need to regenerate any time an input file is newer than the
generated script.

Bug: https://bugs.openjdk.java.net/browse/JDK-8196356


In addition to `hg status` showing no changes, I think it will continue

to

confuse people to generate it into a hidden directory. Was there any
consideration to generating into a regular directory?



I agree. Also, we still generate the configure.sh into the source tree even
if the output directory is somewhere else. I always keep my output
directories separate from the source tree. Sometimes my source directory is
even on a read-only share. I would prefer and also expect any temporary
files to be placed in the output directory resp. the current directory, not
in the source tree. Would that be possible?

Thanks and Kind Regards, Thomas



-Alan

Re: RFR: JDK-8196356: Changes to m4 files don't trigger autoconf execution at build time

[Magnus Ihse Bursie]

On 2018-02-10 09:12, Alan Bateman wrote:

On 08/02/2018 17:49, Erik Joelsson wrote:
The check for when to generate the generated configure script is not 
working quite as expected. It currently only compares timestamps if 
the local repository has any local changes in the make/autoconf 
directory. This used to make sense when we had a committed generated 
script, but now we actually do need to regenerate any time an input 
file is newer than the generated script.


Bug: https://bugs.openjdk.java.net/browse/JDK-8196356
In addition to `hg status` showing no changes, I think it will 
continue to confuse people to generate it into a hidden directory. Was 
there any consideration to generating into a regular directory?


Why would hidden files be confusing? Or, rephrased, how is this any more 
confusing than other hidden directories, such as .idea or .jib? I 
modelled the behaviour on jib. In fact, I was considering using the same 
directory (.jib), but since the name was so specialized, it felt like 
misusing it. That's why I gave it a more general name. (In fact, I 
believe, if .build had been present when jib was created, it would have 
used that instead of creating the specialized .jib directory).


/Magnus

Re: RFR 8190378: Java EE and CORBA modules removal

[Martijn Verburg]

One could almost shed a tear - of joy!  This is exactly the use case for
the module system that the developer community at large will understand.
Thanks for this change and a leaner meaner JDK.

Cheers,
Martijn

On 8 February 2018 at 13:37, Lance Andersen 
wrote:

>
> > On Feb 8, 2018, at 3:04 AM, Alan Bateman 
> wrote:
> >
> > On 07/02/2018 16:57, Lance Andersen wrote:
> >> Hi all,
> >>
> >> I think we are at a point where we are ready to start reviewing  the
> changes to remove the Java EE and CORBA modules as JEP 320, JDK-8189188,
> has been  targeted to JDK 11.
> >> The CSR for removing the modules has been approved:
> https://bugs.openjdk.java.net/browse/JDK-8193757 <
> https://bugs.openjdk.java.net/browse/JDK-8193757>
> >>
> >>  The open webrev can be found at:  http://cr.openjdk.java.net/~
> lancea/8190378/open_changes/  lancea/8190378/open_changes/>
> >>
> > 800 KLOC deleted, wonderful!
> >
> > The update to technology-summary.html page means its html title no
> longer matches the contents. We should probably change it to "JCP
> Technologies in JDK 11" for now.
>
> I updated the webrev. Thanks for catching that (btw we missed this for JDK
> 10)
> >
> > The removal of test cases from the tests in tools/launcher/modules
> removes most of the test coverage for the upgrade module path. We'll need
> to replace these sub-tests. Can you create an issue to track that?
>
> I can do that
> >
> > Everything else looks good and it's okay to track residual issues with
> other JIRA issues. I think the important thing is to get this monster patch
> into JDK builds soon so that libraries and the eco system can start to
> adjust.
>
> Thank you Alan for the review
>
> Best
> Lance
> >
> > -Alan
>
>  
>   <
> http://oracle.com/us/design/oracle-email-sig-198324.gif>
>  Lance Andersen|
> Principal Member of Technical Staff | +1.781.442.2037
> Oracle Java Engineering
> 1 Network Drive
> Burlington, MA 01803
> lance.ander...@oracle.com 
>
>
>
>