On Mon, Oct 1, 2012 at 5:50 PM, Kenny, Jason L <[email protected]> wrote: > Thanks Gary. > The devil is in the details.... > >>> > I'm not sure what you're asking above, and your cut & paste is a little off. > The intent is, if the prefix ends with a space, add the prefix (without the > space) to the result list as a separate element. > That supports linkers that instead of -lfoo might need -l foo as two args. > (Note that without this, it would end up getting quoted by the quoting logic > as "-l foo"). >>> > This clears up the logic a little. But seems very C/C++/Fortran based. I > honestly do find the "" logic messes up more than it helps. I guess I view > this a little buggy as I would think that the idea of quoting an item because > it has a space, vs making a separate item error prone and acquired.
OK, what does it mess up? How is it error-prone? I think you're saying it's unexpected behavior. I agree with that. Feel free to propose an alternative. If you think about it, though, that change will percolate all the way up to being user-visible (it has to be, if for instance you were going to have LIBPREFIX and LIBPREFIX_SEPARATE_ARG or whatever). But I don't think this is that egregious; to me it seems like a clever escape hatch to allow for a corner case without causing too much code churn. It should be documented though. > If you think about LIBS, you mostly want the pre/suffixes added (-lfoo for > instance). But passing through File nodes allows you to specify a particular > version of a lib (as well as static vs. shared) by passing a Node > representing the file. I don't think there's a use case for Value nodes, so > who knows what the right thing is. Directory nodes are interesting; one > could argue they should be passed through as well, for the same kinds of > reasons. I just don't think this code gets called on Directory nodes much. >>> > > I guess I not sure how one makes portable binaries by doing this on posix > systems. Normally this hard codes a path in binary, and causes other > complication from what I know. Honestly I was always under the view that if a > gave a node here it would prevent the need to scan for it, saving a little > time, and would ideally split the node to a libpath + lib value as expected > on the system. SCons isn't just about building portable binaries. We get asked all the time how to make sure the linker uses a static or dynamic lib; it's not really possible in SCons (in general) without passing Nodes through unmodified. > I guess given the code that exist node objects are passed in all the time to > this API... for example if you look at _concat(...) there is a call to: > l = f(SCons.PathList.PathList(list).subst_path(env, target, source)) > in this case l is a list of node objects given the path list was able to map > the subst() value to a node. ( Which is sort of funny that we map the node to > a string then back to a node). Given this, a case such as LIBPATH is given > list of directory nodes which makes it very common. It seems to me that the > lib case is come special case, that can cause issue on other toolchain in > which you would want the file object to get some prefix. Take a manifest > files for example. I'm not sure how the above line of code is relevant to prefix/suffix addition. But I do see your point about LIBPATH; that must go through _concat_ixes. I guess that argues for leaving the code as is, right? (You wouldn't want elements of LIBPATH to be put on the link line without -L preceding them.) -- Gary _______________________________________________ Scons-dev mailing list [email protected] http://two.pairlist.net/mailman/listinfo/scons-dev
