Open StephanTLavavej opened 7 months ago
Alternatively, Boost.URL could be changed to avoid constructing such horrifically long command lines
I think, this cannot be avoided really. It's just a list of object modules to link, and it has most of them...
Perhaps - but somehow, every other Boost library hasn't triggered this problem.
That's because of the it has most of them...
part I believe. Others did not need this structure, but url
for whatever reasons did. There is nothing inherently bad in structuring your source code over many files, if it's more convenient.
I suppose that's fair, so Boost.Build should be fixed - either the command-line length hack, or a true fix to avoid backslash escaping.
Thank you!! :heart_eyes_cat:
The msys2/MINGW-packages project has a patch: https://github.com/msys2/MINGW-packages/blob/ca4e304acefff6f0e145a14c6419d3fd78bcfa2e/mingw-w64-boost/0012-allow-longer-path-on-mingw-w64.patch @AndrewSav brought this to my attention in https://github.com/StephanTLavavej/mingw-distro/issues/90#issuecomment-1874504412 and explained:
This should be upstreamed to Boost.Build, which will allow it to handle Boost.URL on mingw-w64. The patch's content looks reasonable to me - it discards the pre-XP codepaths (Boost.Build really doesn't need to worry about someone attempting to build Boost on such incredibly ancient systems), then it allows toolsets targeting Windows (as this is execnt.cpp) that aren't imitating MSVC (i.e. that aren't defining
_MSC_VER
) to use longer command lines. This seems like a reasonable heuristic to distinguish "mingw-w64 via MSYS2" from "MSVC via cmd".Alternatively, something in Boost.Build could be fixed to properly handle backslashes when using response files on MSYS2.
Alternatively, Boost.URL could be changed to avoid constructing such horrifically long command lines (in 1.84.0, it is the only Boost library to be affected by this problem).