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

[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 outside the source tree.

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

[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 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 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?


-Alan