Hi,
I'll second Jason that we have Never(?) credited -j6 as a cause of CI
failures; even for some of the unexplained ones -j6 seems an unlikely cause.
That said I never use -j and I never rely on advice that says I don't need
to worry that dependencies or cmake files or innards are unlikely sources
of error. I have a bounty of cleaning shortcuts; of note here are these:
./clean_build
#to remove modified files from the current subdirectory tree:
a gitclean 'git ls-files -m | xargs -t rm'
#and get back whats gone
a gitback 'git ls-files -d | xargs -t git checkout --'
#to purge every untracked file from your tree:
a gitsuperclean 'git clean -fxd'
I also follow my own advice, eg, commit early, commit often.
After many moons of software development i have learned to never wait on
compilers, linkers, etc. There are simply too many other things to do.
scott
On Fri, Apr 08, 2022 at 01:04:46PM -0400, Jason Swails wrote:
> CI uses `make -j6` (
> https://gitlab.ambermd.org/amber/amber/-/blob/master/devtools/ci/jenkins/build_test_cmake.sh#L38),
> so parallel make gets exercised every PR as well.
On Fri, Apr 08, 2022 at 09:41:25AM -0700, Scott Le Grand wrote:
> I'm not specifying a processor count - I would have assumed that would mean
> a single process but I have seen dependency issues before and it does seem
> to be a bug in the build that emerged in the past few years. This doesn't
> seem like an acceptable dilemma for end users.
On Fri, Apr 08, 2022 at 08:57:33PM +0000, Jamie Smith wrote:
> Removing the CMakeCache.txt file forces a complete reconfigure and rebuild of the project, and only needs to be done in a few situations:
> - If the build scripts have been modified in a way that they're incompatible with an older cache file and causing errors (rare but it can happen)
> - If a library on your system that Amber links to has been deleted or moved (CMake will likely cache the original location and then the build will error out)
> - If the build or source dirs themselves have been moved to a different absolute path
> - As a last resort if you're dealing with a weird build error and you suspect it's due to stale modules / libraries in the build dir.
>
> In all other situations, you should be be able to just rerun cmake with the existing cache, and it should be able to do an incremental reconfigure and go a lot faster.
>
> Hope that makes sense,
> Jamie
>
> P.S. If you want to do a clean build, it's actually better to just rm -rf * in the build directory than to delete the cache. That way you also clear out any old fortran modules that may be hanging around.
>
> ________________________________
> From: David A Case <david.case.rutgers.edu>
> Sent: Friday, April 8, 2022 8:18 AM
> To: AMBER Developers Mailing List
> Subject: Re: [AMBER-Developers] 3rd attempt to merge energy drift fix
>
> On Fri, Apr 08, 2022, Dave Cerutti wrote:
>
> >I didn't know that the -j
> >flag works with our cmake installation--my experience was that trying to
> >make with -j8 got me into trouble
>
> FWIW, I use -j4 or -j6 all the time (depening on how many cores I have on
> the machine I am using.) That said, it is certainly possible that there is
> some problem with dependencies that leads to intermittent problems. These
> dependencies are built by cmake (which should be an advantage compared to the
> hand-built perl scripts we used to use to generate dependencies), but it
> depends both the on the accuracy of the information we give to cmake, and on
> its internal ability to create the correct connections.
>
> I *do* find it hard to know when one needs to rm the CMakeCache.txt file when
> re-running cmake itself. My inclination is to always do this, even if it
> takes a few extra seconds at the build stage.
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Sat Apr 09 2022 - 13:30:03 PDT
