#63834 closed defect (fixed)
legacy-support: can't read "ls_cache_incpath": no such variable
Reported by: | ryandesign (Ryan Carsten Schmidt) | Owned by: | cjones051073 (Chris Jones) |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | 2.7.1 |
Keywords: | Cc: | danchr (Dan Villiom Podlaski Christiansen) | |
Port: | mercurial legacy-support |
Description
While mirroring mercurial, this error occurred, which seems to relate to legacy support:
https://build.macports.org/builders/jobs-mirror/builds/327006/steps/mirror/logs/stdio
Error: mportopen file:///opt/local/var/buildworker/jobs/jobs-mirror/build/ports/devel/mercurial failed: can't read "ls_cache_incpath": no such variable
Change History (12)
comment:1 Changed 3 years ago by cjones051073 (Chris Jones)
comment:2 Changed 3 years ago by jmroot (Joshua Root)
Mercurial doesn't use legacysupport directly, but via cargo_fetch.
comment:3 Changed 3 years ago by ryandesign (Ryan Carsten Schmidt)
Right, with the +rust variant.
This is not a new problem nor intermittent; I see it in every mirroring log for mercurial I've looked at.
comment:4 Changed 3 years ago by jmroot (Joshua Root)
Only affects older OS versions apparently (presumably ones on which legacysupport is active). Debug output:
% port -d info mercurial +rust DEBUG: Changing to port directory: /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/devel/mercurial DEBUG: OS darwin/10.8.0 (macOS 10.6.8) arch i386 DEBUG: Sourcing PortGroup compiler_wrapper 1.0 from /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/_resources/port1.0/group/compiler_wrapper-1.0.tcl DEBUG: Re-registering default for distname DEBUG: Re-registering default for build.cmd DEBUG: Re-registering default for build.target DEBUG: Re-registering default for destroot.cmd DEBUG: Re-registering default for destroot.destdir DEBUG: Re-registering default for destroot.target DEBUG: Sourcing PortGroup python 1.0 from /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/_resources/port1.0/group/python-1.0.tcl DEBUG: adding the default universal variant DEBUG: Reading variant descriptions from /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/_resources/port1.0/variant_descriptions.conf DEBUG: Executing variant rust provides rust DEBUG: Sourcing PortGroup compiler_blacklist_versions 1.0 from /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/_resources/port1.0/group/compiler_blacklist_versions-1.0.tcl DEBUG: Sourcing PortGroup legacysupport 1.1 from /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/_resources/port1.0/group/legacysupport-1.1.tcl DEBUG: Re-registering default for dist_subdir DEBUG: Re-registering default for extract.only DEBUG: Sourcing PortGroup muniversal 1.0 from /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/_resources/port1.0/group/muniversal-1.0.tcl DEBUG: Sourcing PortGroup cargo_fetch 1.0 from /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/_resources/port1.0/group/cargo_fetch-1.0.tcl DEBUG: Running callback portconfigure::add_automatic_compiler_dependencies DEBUG: Chosen compiler macports-clang-11 is provided by a port, adding dependency DEBUG: Adding depends_build port:clang-11 DEBUG: Adding depends_lib libcxx DEBUG: Adding depends_skip_archcheck clang-11 DEBUG: Finished running callback portconfigure::add_automatic_compiler_dependencies DEBUG: Running callback portbuild::add_automatic_buildsystem_dependencies DEBUG: Finished running callback portbuild::add_automatic_buildsystem_dependencies DEBUG: Running callback portstartupitem::add_notes DEBUG: Finished running callback portstartupitem::add_notes DEBUG: Running callback compwrap::configure_envs DEBUG: Finished running callback compwrap::configure_envs DEBUG: Running callback python_add_dependencies DEBUG: Finished running callback python_add_dependencies DEBUG: Running callback legacysupport::add_legacysupport DEBUG: legacysupport: Will append path:lib/libMacportsLegacySupport.dylib:legacy-support to depends_lib DEBUG: can't read "ls_cache_incpath": no such variable while executing "if { ${ls_cache_incpath} ne "" } { foreach f ${ls_cache_ldflags} { configure.ldflags-delete ${f} } foreach f ${ls_cache_cppfl..." (procedure "legacysupport::add_legacysupport" line 11) invoked from within "${callback}" (procedure "port::run_callbacks" line 5) invoked from within "port::run_callbacks" invoked from within "$workername eval {port::run_callbacks}" (procedure "mportopen" line 66) invoked from within "mportopen $porturl [array get options] [array get merged_variations]" Error: Unable to open port: can't read "ls_cache_incpath": no such variable
comment:5 Changed 3 years ago by ryandesign (Ryan Carsten Schmidt)
Yes, there we go. I can reproduce it on High Sierra with:
port info mercurial +rust legacysupport.newest_darwin_requires_legacy=99
(The machine doing the mirroring still runs El Capitan.)
comment:6 Changed 3 years ago by jmroot (Joshua Root)
So yeah, whenever the callback actually does something, it breaks. I would guess it's because it's including a portgroup inside a variant, which means some things that the portgroup code thinks will be run in a global context are actually run in a proc context. There's a reason why PortGroup is only supposed to be used at the top of the Portfile.
comment:7 Changed 3 years ago by jmroot (Joshua Root)
Cc: | danchr added |
---|---|
Port: | mercurial added |
comment:8 Changed 3 years ago by ryandesign (Ryan Carsten Schmidt)
But mercurial only needs cargo_fetch in the rust variant. The cargo_fetch portgroup does a bunch things immediately when it's included. Will that mess up the mercurial port when the rust variant is not selected?
comment:9 Changed 3 years ago by jmroot (Joshua Root)
Probably yeah. It's not a great design. Workarounds could be to include the portgroup conditionally with variant_isset, or maybe somehow make legacysupport work regardless of the context it runs in?
comment:10 Changed 3 years ago by cjones051073 (Chris Jones)
If anyone has suggestions what to do make the cargo_fetch/legacysuppoirt PG work better when included inside a variant I am open to suggestions. I guess the 'problem' lines are the global variable caches at
if anyone has suggestions what to do with these instead, I am open to suggestions.
To me though the simpliest solution is to avoid including PGs in this way, in which case Joshua's suggestion of
if {[variant_isset rust]} { PortGroup cargo_fetch 1.0 }
at the top of the mercurial Portfile, seems the best fix.
comment:11 Changed 3 years ago by Chris Jones <jonesc@…>
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
comment:12 Changed 3 years ago by ryandesign (Ryan Carsten Schmidt)
Thanks, I agree that does work around the problem.
Idon't see anything wrong with what the legacysupport PG is doing with this variable. It must relate to something the port is doing ?