This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
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