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


> 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.

That is a sound principle in the abstract.  But here I think we can just
come up with something reasonable that is general enough but not overly
general.  Then the uses can be made to conform to what that scheme needs.

> 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.

Those are currently almost build-time checks rather than actually being
tests like other libc tests.  So you're suggesting turning them into libc
tests instead.  But they are not intended at all to test what they're built
with, they're generic programs to test ELF files passed as arguments.  The
wrong #if in check-textrel.c could easily be replaced with either a trivial
sysdeps header to define one macro, or (better) with a command-line flag so
that the program itself is entirely generic and a sysdeps Makefile just
chooses whether to pass the flag.

These are things that it's pretty trivial to make 100% cross-friendly
without involving any run-tests-on-the-host machinery at all.  It seems
wrong to move them in the opposite direction just to avoid some pretty
straightforward makefile work that we need for rpcgen anyway.

In fact, those three all look like they could be done pretty easily just by
scripts that run readelf.  Perhaps that's the right clean-up for those.
Incidentally, it might get us down to having no uses of native-compile.

> (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.)

I've never looked at any of those in detail.  But I agree their purposes
seem sufficiently related that they probably ought to be consolidated.
Doing this sort of thing with scripts rather than C programs makes sense.


Thanks,
Roland


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