Closed mwkrentel closed 1 year ago
Thanks for the detailed report.
This is a bug. We will fix it soon.
I see that you solved the issue with a local workaround. Is this workaround good enough for your usage? Is this an urgent issue for you? Can it wait for a week or two? (I can send you a fixing patch in an urgent case)
Yes, I have a satisfactory workaround for spack. So, there's no rush to commit a fix, take your time. I'm just happy that you consider it a bug.
Great. Thanks.
@mwkrentel - Please check External Release v2023.06.07
Yes, it works now, both for renaming xed and mbuild. Thanks!
There is an issue beginning with v2023.04.16 where building XED with xed and mbuild clones, the
xed
directory must be named exactlyxed
, notxed-old
orxed-new
or anything else.How to reproduce:
Pick a directory with a fairly short path from
/
. In this case, I'll use/tmp/krentel/work
.Inside
work
, clonembuild
andxed
, except renamexed
to something else likerepo
.So, the contents of
/tmp/krentel/work
are:The
repo
directory is the clone ofxed
, just renamed asrepo
.Check the path from
work
to/
to make sure there are no adjacent directories namedxed
, so no/xed
,/tmp/xed
,/tmp/krentel/xed
, etc. That's the reason for picking a short path to/
.Now, cd to
repo
and runmfile.py
.It dies trying to find the
scripts
directory of the subdirectoryxed
. It works ifrepo
is named specificallyxed
, but nothing else.But the strange thing is that it works if I create an empty directory
xed
as a sibling torepo
and build insiderepo
.This suggests that something is looking for the
scripts
directory as a subdir ofxed
but then not using it, at least not for this part of the build.Note: it also fails in the same way if
mbuild
is named something else.mbuild
can be in a different location (not sideways toxed
) by settingPYTHONPATH
, but it still has to be calledmbuild
. For example, if I renamembuild
asfoo
and setPYTHONPATH
,Notes:
This is new behavior (searching for scripts) starting with v2023.04.16. This works fine with v2022.10.11.
This fails on any version of Linux. I've tested RH 8.x and Ubuntu 20.04 and 22.04.
It doesn't depend on the version of python.
The critical thing is that there is no upwards directory (or file) named
xed
that would cause the script to return success. That's the reason for picking something close to/
.Now, you may consider this not to be a bug and just dismiss. But let me suggest a few things.
One, this is new to 2023.04.16. And it's looking for the
scripts
directory but not using it. This suggests that your build scripts are not doing what you think they're doing. You may run into more serious problems later and better to clean it out now before it becomes too entrenched.Two, I often build multiple versions of a package for comparisson. For example, I might want to build
xed-old
,xed-new
,xed-patched
, where none are named exactlyxed
. Why should this not be allowed??Finally, this change broke my spack recipe and took me nearly a week to track down. :-( (Spack renames all source dirs to
spack-src
.)https://github.com/spack/spack/pull/37582