[Scons-dev] Subst API...

[Gary Oberbrunner]

On Mon, Oct 1, 2012 at 5:50 PM, Kenny, Jason L <jason.l.kenny at intel.com> 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