Hi Magnus , On Mon, 2013-12-02 at 14:55 +0100, Magnus Ihse Bursie wrote: > On 2013-11-22 14:34, Dave Pointon wrote: > > I don't know if it's of any help, but I've noticed that configure > > sometimes needs to be run twice before the additional/new/modified > > option(s) take effect - quite frequently, the first time is merely a > > re-run of the previously generated generated-configure.sh. > > That sounds weird. I've never seen that behavior, and I can't really > imagine how that could happen. Do you have any debug information about that? >
Yep, it seemed v. weird to me, but I've now tracked the errant deterministic behaviour down to local changes I made WRT the work I've been doing on the JDK build variant 'improvements' (for which, see the thread 'Improving the management and accessibility of the handling of JDK variants') - suffice it to say that this behaviour was only observed to manifest itself whilst I was been 'playing' :-) > What definitely *could* (and typically will) happen is that files are > not re-compiled with new options due to a new configuration. But that is > not helped by running configure again, but by running "make clean". > > And if you really want to be on the safe side, it's probably a good idea > to do "make dist-clean" before re-running configure. This will delete > everything, including the old configuration. > TFT, I know of distclean in CPAN modules, but didn't realize it has a close relation in the OJDK. > /Magnus > Rgds , -- Dave Pointon FIAP MBCS Now I saw, tho' too late, the folly of beginning a work before we count the cost and before we we judge rightly of our strength to go thro' with it - Robinson Crusoe
