Opened 7 years ago

Closed 6 years ago

#1563 closed bug (fixed)

Changing configure options does not clean build dir

Reported by: gropp Owned by: gropp
Priority: major Milestone: future
Component: mpich Keywords:
Cc:

Description

Some of the nightly build failures appear to be due to using stale object files after changing the configure options (since the same build directory is used for each of the test builds), such as changing to a different device. The previous configure tried to be more careful about this, and forced a make clean when arguments to configure changed.

One workaround is to require users to always and without fail remember to execute "make clean" before "make". This is unlikely to be 100% successful :) I'm opposed to such a fragile solution.

Another option would be to rely on dependency checking, but this will need a fallback in the case where the dependency information cannot be created.

Change History (7)

comment:1 Changed 7 years ago by goodell

I've just committed a fix for the PGI compiler dependency info ([beadd1c6c3da1107a52c9f9a2feac9a2fdbc5d06]). So hopefully that will help substantially with the specific problem we are seeing in the nightlies. Other exotic/bizarre compilers may still be missing a dependency generation mechanism.

I'm not fond of a forced "make clean" whenever the configure options change. This is something that I always found infuriating when working with simplemake. I frequently change the configure options in ways that are safe enough to avoid a complete "make clean". The extra complete rebuilds are a big time sink.

I am a fan of requiring a user-initiated "make clean" when substantially changing configure options. It's not that hard to do, or even to remember to do. And very few of our real users build MPICH2 with more than one configuration.

The nightly tests ought to be putting a "make clean" in the process, probably right after "make install" to ensure that there are no surprising dependencies on the build tree after installation.

comment:2 follow-up: Changed 7 years ago by gropp

I disagree. Our own documentation on building MPICH2 does not include that initial "make clean" step, and one of the purposes of the nightlies is to discover problems that our users may have, which includes reconfiguring and rebuilding. It was an explicit decision not to include a make clean to ensure that our build process was robust enough to avoid bug reports unnecessarily caused by leftovers in the build directory.

Handling the case of changing configure options is tricky. How does one know, with 100% accuracy, that a configure change does not require a make clean? In other areas, we appear to be erring on the side of safety, why not here? One option would be to allow very knowledgeable developers to suppress the clean-on-change but retain it for everyone else.

comment:3 in reply to: ↑ 2 Changed 7 years ago by goodell

Replying to gropp:

It was an explicit decision not to include a make clean to ensure that our build process was robust enough to avoid bug reports unnecessarily caused by leftovers in the build directory.

I think that was the wrong decision.

Handling the case of changing configure options is tricky. How does one know, with 100% accuracy, that a configure change does not require a make clean? In other areas, we appear to be erring on the side of safety, why not here? One option would be to allow very knowledgeable developers to suppress the clean-on-change but retain it for everyone else.

We don't know with 100% accuracy. Actually, we don't even know with 100% accuracy that something hasn't changed in the system between invocations of "make". Someone could upgrade/downgrade the compiler between the two runs and invalidate the results of our configure tests. So we expect the user to "make clean", etc. in this case.

If this clean-on-change is added (which I don't think it should be), then allowing it to be disabled is very important to keep the development cycle from being even slower than it already is.

comment:4 Changed 7 years ago by gropp

This clean step was added as a result of time lost by other developers because changing the configure parameters and rebuilding caused the wrong objects to be used - this wasn't done speculatively but in response to a very real problem.

Your argument about 100% is technically true but misses the point - there are many interactions within the configure system, and (as noted above) failing to remember to clean the directories can (not may) cause problems. And we often tell users to reconfigure in order to fix problems.

comment:5 Changed 6 years ago by balaji

  • Milestone set to future
  • Owner set to gropp
  • Status changed from new to assigned

comment:6 Changed 6 years ago by gropp

I'm not going to do anything with this bug. There is no consensus on the correct solution. Resolving and we will have to live with the behavior.

comment:7 Changed 6 years ago by gropp

  • Resolution set to fixed
  • Status changed from assigned to closed
Note: See TracTickets for help on using tickets.