You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The mason link command collapses all linked packages into an unversioned directory structure. This was inspired by the hombrew link command and is useful if you want to install lots of dependencies with mason and point to a single, predictable, location for their headers and libs.
However, per chat with @kkaefer we want to move to a future where all apps using mason for deps consistently use the mason client (either mason.cmake or mason bash client) to fetch versioned paths. Removing mason link will remove surface area to maintain and limit the amount of ways downstream apps use mason. By using the mason client we can help downstream apps using mason packages without suffering through difficultings of using existing *-config tools that likely will not work with the relative structure of mason packages, like pkg-config, freetype-config, or gdal-config. For example code like
could be avoided if we started to make no promise that gdal-config works in mason packages (or even removed packaging it) because we only support downstream apps using the mason client to get include and lib paths.
Note: there are a lot of uses of mason link, so only proposing deprecating and not removing. I imagine I'll need several months at least to migrate all usage off mason link in external repos like
/cc @kkaefer I've been looking at various mason link usage. It is widespread for a reason: it is useful to collapse down paths to predicable places. This helps enormously with node-gyp binding.gyp situations. I'm no longer thinking it is feasible to deprecate this and I'm going to close this issue and plan to keep supporting link. If people have feedback about the design of it, feel free to open new issues.
This helps enormously with node-gyp binding.gyp situations.
Can you please describe how it helps there? Instead of providing the one .link directory, can we just supply paths to all individual directories (that's how we did it in Mapbox GL Native when we were using gyp). The massive flaw of link is still that it completely breaks any setups that use more than one architecture (cross-compiling), and that it breaks setups that upgrade dependencies.
The
mason link
command collapses all linked packages into an unversioned directory structure. This was inspired by the hombrewlink
command and is useful if you want to install lots of dependencies with mason and point to a single, predictable, location for their headers and libs.However, per chat with @kkaefer we want to move to a future where all apps using mason for deps consistently use the mason client (either mason.cmake or mason bash client) to fetch versioned paths. Removing
mason link
will remove surface area to maintain and limit the amount of ways downstream apps use mason. By using themason client
we can help downstream apps using mason packages without suffering through difficultings of using existing*-config
tools that likely will not work with the relative structure of mason packages, likepkg-config
,freetype-config
, orgdal-config
. For example code likemason/scripts/gdal/2.1.3/script.sh
Lines 154 to 174 in 1319207
gdal-config
works in mason packages (or even removed packaging it) because we only support downstream apps using themason
client to get include and lib paths.Note: there are a lot of uses of
mason link
, so only proposing deprecating and not removing. I imagine I'll need several months at least to migrate all usage offmason link
in external repos likeThe text was updated successfully, but these errors were encountered: