Testing ports/patches on non-i386 (such as amd64)

[Chuck Swiger]

Daniel Roethlisberger wrote:
> What's the best way to handle such a situation as port maintainer?
> Should I file a PR asking for a committer to test my patches? Or should
> I find someone able and willing to do some testing for me through other
> means, such as posting patches to this list? Or should I just go ahead
> and have the untested patches committed, and wait for the bento logs to
> tell me about success or failure? (I don't particularly like this one).
> Any other options?

If you want to make sure your port works properly on the SPARC or Alpha, for 
example, having access to a machine of that type is very helpful.  You might 
ask on the appropriate freebsd-sparc, freebsd-alpha, etc mailing list whether 
someone will test your port or give you a login so you can do the testing 
yourself.

If noone responds, it's likely that you can not worry about that platform 
until someone does run your port and does run into a problem.  :-)

In the meantime, you can make changes to the software in a fashion that are 
platform-independent using C99 concepts; use portable datatypes such as 
intXX_t's rather than depending on sizeof(short) = 2 and sizeof(int) = 4, etc, 
particularly in struct's which are persisted in data files or sent over the 
network; you can avoid depending on fancy platform-specific analysis like GNU 
autoconf [1]; compile using -Wall and fix any warnings, pay attention to 
implicit conversions and casting when dereferencing pointers, etc.

While you're there, one can also herd the code towards using snprintf() rather 
than sprintf() to try to avoid buffer overflows, using malloc() and [*gasp*] 
actually checking it's return value, rather than using automaticly allocated 
arrays on the stack, and so forth.  None of this is rocket science.  There's a 
lot of sloppy code of there, though...

-- 
-Chuck

[1]: The notion of conditional code which depends on actual tests of the local 
platforms capabilities is fine, to the extent that doing so is actually 
useful.  However, autoconf has long since passed the point of being the tail 
wagging the dog in that it often takes longer to run ./configure than it does 
to actually build the program itself, when every ./configure run contains 
hundreds of lines of the same tests as every other, when the program code 
contains a maze of twisty little #ifdefs, all alike, when testing for 
sizeof(int) and the like encourages people to write code which depends on 
these conditionals rather than simply using a portable approach from the 
start, testing the maximum size of the argument list (and wasting lots of CPU 
time doing so) and hardcoding that value into the executable when that 
"maximum size" may well change if someone switches which shell they use or 
recompile the kernel, etc.

[ I guess I pressed one of my own buttons here.  :-) ]