This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Cross-rpcgen patch, version 4


On Wed, 25 Apr 2012, Roland McGrath wrote:

> > The rationale for not including -c is that there is exactly one place 
> > right now that has a use for it with -c (cross-rpcgen) and exactly one 
> > that has a use for it without -c ($(native-compile)), so the above 
> > (whatever the name) seems to be the limit of useful sharing between those 
> > two cases.
> 
> I understand.  But the point of calling it build-compile-command.c is to
> have a clear parallel with the existing compile-command.c, so if you're
> going to have a subtle but crucial non-parallelism then it defeats the
> whole purpose.

Looking at compile.c and compile-command.c, *both* include -c - the 
difference is the addition of $(OUTPUT_OPTION) $(compile-mkdep-flags) in 
compile-command.c.  So that would suggest some different name entirely for 
this variable that doesn't include -c.  $(build-compile-cc)?

> The long-run answer is probably that we should have some more first-class
> machinery for build-compiled stuff rather than just the ad hoc stuff.  For
> the trivial cases we have today where native-compile is adequate, it was
> easy enough to do it ad hoc and so we never bothered with anything else.
> With rpcgen and the prospect of other such things, it may be worth the
> trouble now.
> 
> If you find that prospect daunting, I can help write the makefile magic.

That would be helpful, but I don't think it makes sense to add such 
infrastructure without having enough ad hoc use cases checked in to see 
what is meaningfully common between them and what needs to vary - this is 
a case where I think you need to have things working first, and refactor 
afterwards if and when there are enough cases for a useful refactoring.  
Two cases is not enough to be able to tell what a general design should 
look like.

Three of the five uses of $(native-compile) I think are actually 
unnecessary: I see no reason why the elf/ testcases using it should 
actually need to use build system libc rather than newly built libc, and 
in the case of check-textrel.c there are architecture #if conditions that 
are wrong if you build it for the build system in a cross testing 
scenario.  (The other two tests using $(native-compile) do run the 
compiler so do need to run on the build system not the system on which 
glibc runs.  But both those tests - posix/annexc and stdlib/isomac - seem 
rather to overlap with the conformtest code, and it might be better to 
standardise on that as the way of testing header contents - in which case 
maybe $(native-compile) could actually go away completely.)

-- 
Joseph S. Myers
joseph@codesourcery.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]