[CXX-286] Support additional custom compiler and linker options when invoking scons (e.g. rpath) Created: 21/Jul/14 Updated: 27/May/22 Resolved: 23/Jan/15 |
|
| Status: | Closed |
| Project: | C++ Driver |
| Component/s: | Build |
| Affects Version/s: | legacy-0.0-26compat-2.6.3 |
| Fix Version/s: | legacy-1.0.0-rc4 |
| Type: | Improvement | Priority: | Minor - P4 |
| Reporter: | Kevin Locke | Assignee: | Andrew Morrow (Inactive) |
| Resolution: | Done | Votes: | 0 |
| Labels: | legacy-cxx | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||
| Server Compat: | 3.0 | ||||||||||||||||
| Description |
|
I have been unable to find a way to build the C++ driver with additional custom linker options. I am currently attempting to build libmongoclient with
Note the mismatch where sometimes $ORIGIN follows -rpath and other times it doesn't. Although this may be a bug, passing linker options as part of the linker command seems like a hack that may not be worth supporting. Although my current use-case could be addressed by adding some rpath options to SConstruct, I suspect the issue may be better addressed with an approach that would allow any custom linker options rather than rewriting every linker option users may need as a scons option. As a better solution, would it be possible to support $LDFLAGS from the environment (as autotools- and cmake-based build systems do) for passing custom linker options? Possibly protected by an option similar to - I think this may be useful for $CFLAGS and $CXXFLAGS as well, but I can file that as another issue if it is worth considering separately. Thanks for considering, |
| Comments |
| Comment by Kevin Locke [ 21/Jul/14 ] |
|
Hi Andrew, Thanks for responding so quickly and thoroughly. That makes a lot of sense and I agree on all points. Feel free to merge this ticket with As for how to delimit the strings, it seems like there is not much consistency in this area between build systems. In building the other libraries for my current project, I have escaped $ORIGIN many different ways in LDFLAGS for the different projects and it is never documented and usually a matter of trial-and-error between escaping for Makefile macros (with $$) and shell escapes (either quotes or backslashes). My recommendation would be to handle word-splitting like the shell (if that's easily possible inside scons) so directories with spaces would need to be quoted or the space escaped, and avoid variable expansion in the passed string, but if that is difficult I wouldn't spend much engineering effort reimplementing shell parsing since anyone going down this road will be used to dealing with trial-and-error escaping. But that's just my 2c at the moment and not a well-researched opinion. Thanks, |
| Comment by Andrew Morrow (Inactive) [ 21/Jul/14 ] |
|
Hi Kevin - There is actually a (not very detailed) ticket requesting this feature (see We should probably offer this for:
We would need to decide whether to use the SCons Variables feature for this, or make these options (--cflags and --extra-cflags, etc.?). An additional question, as you point out, is quoting. If using the Variables feature, how should this work if you want to pass several flags? Should they be comma delimited? A quoted space delimited string seems easiest, but then there are problems with things like spaces in paths. Similar subtleties exist with making them --options. And there are probably still some issues to be considered re escaping things like $ORIGIN as you mention. Finally, please note that this work would be done on the legacy branch, but it is unlikely that it would be backported to the 26compat branch, since that is now a maintenance release series. |