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

2018-02-12 Thread 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

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

2018-02-12 Thread 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

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

2018-02-12 Thread 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

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

2018-02-12 Thread 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

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

2018-02-12 Thread 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

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

2018-02-10 Thread Martin Buchholz
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

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

2018-02-10 Thread Thomas Stüfe
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

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

2018-02-10 Thread Alan Bateman
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

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

2018-02-08 Thread Tim Bell
Erik: 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