Bruno Haible <[EMAIL PROTECTED]> writes: > "For testing portability, invoke 'gnulib-tool --import check-portability' > (or check-portability-unix if mingw is not among your portability targets), > then compile the program and look at the link time warnings. Use > gnulib-tool --import with all the mentioned modules; all portability > warnings will then disappear, and your program will be portable."
A problem with this is that there will be false alarms in the link time warnings. The user will figure this out and ignore them. But the next time they redo the portability-testing step, the same false alarms will be generated. There should be a way to shut off the false alarm in the source code. That is what I was proposing "#undef ctime" for (in system-dependent code that can assume a ctime with well-defined behavior no matter what the argument is). If I compile coreutils that way I get plenty of false alarms. I don't know whether any of them are valid (I haven't checked them recently, there were too many and I didn't have time, but the first few were false). Also, I have some qualms about the whole idea of of "gnulib-tool --import check-portability" step. It'd be nicer if we could just ask people to compile with -DGNULIB_POSIXCHECK or whatever. That way they won't have to use gnulib-tool, and the test can be done by installers rather than just maintainers. > What precisely is the use case that you imagine? m4/foo.m4 has determined that foo doesn't work and ordinary code shouldn't use it directly, but some ordinary code uses it anyway. (Sorry, I'm not sure whether this is precise enough, but it's late....)
