[llvm-commits] [llvm-gcc-4.2] r54702 - /llvm-gcc-4.2/trunk/gcc/Makefile.in

[Jim Grosbach]

On Aug 15, 2008, at 9:20 AM, Chris Lattner wrote:
> On Aug 15, 2008, at 8:58 AM, Jim Grosbach wrote:
>
>> I'm open to suggestions for alternatives; however, without this or
>> equivalent, the build is fundamentally broken on Darwin.
>
> Can you base this on a flag passed into the build_gcc script like the
> target arch's?

That was my first thought, too, once I figured out that I was getting  
a dylib w/o ARM support even when building an ARM compiler. However,  
the dylib is built at a much lower level than build_gcc. The  
information about what other targets are also being built by the meta- 
script is no longer available. That's appropriate. The information  
about what other targets are also being built shouldn't be needed when  
building any individual target. This part of the build requiring that  
information is indicative that either building the dylib at this step  
is improper, or that the way we use the dylib in build_gcc is improper.

Essentially, either the dylib is tied to a particular target build of  
llvm-gcc and using it outside of that context is improper, or the  
dylib is independent of any particular target build and pulling it out  
of a specific build is improper. Depending on which perspective we  
choose to adopt, we can modify the infrastructure to deal with it.  
Both are solvable problems.

It's worth noting that it is not unreasonable to envision supporting  
building for multiple targets in a step-wise manner (i.e., multiple  
invocations of build_gcc, each creating a compiler installation, and  
then merging the results to obtain the final image). In that scenario,  
the full set of target architectures is never available at any stage  
and could not be passed down from build_gcc. That is, relying on the  
full set of targets being available when building for any single  
target is inherently fragile and should be avoided if possible.

Note that none of this is unique to ARM. The x86/ppc bits already do  
this in the exact same manner to solve this same problem.

My proposal is that if we want to truly fix these bits to be a cleaner  
build architecture, that it should be done as a two-step process.  
First, utilize the existing infrastructure to accomplish the task at  
hand. Second, refactor the infrastructure into a more elegant form.  
Whenever possible, I prefer not to co-mingle refactoring work with  
feature work.