Gary,

On Oct 20, 2012, at 2:52 PM, Gary Oberbrunner <ga...@oberbrunner.com> wrote:

> 
> 
> On Sat, Oct 20, 2012 at 12:01 PM, Gary Oberbrunner <ga...@oberbrunner.com> 
> wrote:
> 
> Indeed, if I can figure a way to make even those tools less hard-wired I will 
> try (so D and the other compilers can be on more of an even footing).
>  
> The problem in the current D code comes from trying to replace the linker 
> (LINKCOM) with the D linker when there are D sources to be linked.  It does 
> this with an action Generator called setSmartLink, that's supposed to return 
> the regular linker command unless there are some D sources, in which case it 
> returns the D linker command.  (The way in which it finds D sources is to 
> look at the source to each linker source, which is not 100% errorproof, but 
> it's OK -- that's for another time.)
> 
> The problem is how it replaces LINKCOM; on Windows LINKCOM is a ListAction 
> where one of the actions is a python method -- and this method doesn't 
> preserve that because it uses the substitution logic, which stringifies it.
> 
> So, since Fortran already has this problem (I'll look at how it solves it), I 
> propose the time-honored method of adding a new level of abstraction in the 
> linker command.  It should *always* run a generator function.  That function 
> will iterate through a list of functions provided by each language, and those 
> languages can inspect the sources and return the actual linker command to be 
> run if the source list looks like its linker is needed.  The default, if no 
> language-specific command generator returns a command, is to just run 
> LINKCOM.  Then we'll need a defined way for languages to add their linker 
> generator to the master list.  There is still the problem of what if they 
> conflict; but that seems to be a hard problem not yet solved by anyone 
> anyway.  (What linker gets used if you have C++ and Fortran?)  We could give 
> a warning and go with the first result, I suppose.
> 
> Does this seem like a reasonable plan?  I haven't looked at the code in 
> enough detail to know how to do it, but it doesn't seem completely insane.

Sounds like a good plan.

So the list would have a callback to each defined tools link com logic which 
could claim the linking by looking at the list of sources.
First to claim wins?
Then we'll need to be careful about the order which link com's are added to the 
list?

I have had the "pleasure" of doing c,c++,fortran code linkage in a 
multi-platform make file (though the platforms were solaris,linux,hpux, aix at 
the time)… ;)

-Bill
_______________________________________________
Scons-dev mailing list
Scons-dev@scons.org
http://two.pairlist.net/mailman/listinfo/scons-dev

Reply via email to