[Nut-upsdev] [nut-commits] buildbot failure in Network UPS Tools on FreeBSD-i686

[Arjen de Korte]

Citeren Arnaud Quette <aquette.dev op gmail.com>:

> great. Until now, I was mixed between the Python configure.ac code,
> that is somehow doing the above manually, and simply disabling
> strptime if we were not sure to have it (an m4 macro would have been
> needed), and possibly reimplementing strptime, which was not an option
> for 1 small feature in 1 sub driver.

So far, all BuildBots (four out of five) that have run this seem to  
accept it without warnings. Hopefully, the fifth will also run fine  
now. Checking if this function is available is mandatory anyway, since  
AC_USE_SYSTEM_EXTENSIONS will only expose built-in functions that are  
hidden (due to potential namespace conflicts). It will not guarantee  
that strptime() (or any other Posix extension for that matter) is  
available.

> I'm currently checking to setup a small team in India to work around
> QA and setting up a buildbot with missing OSs. I hope that this will
> give us more visibility for such changes, though it won't be available
> before some months.

What remains to be done is to add a few lines to the developer  
documentation how to deal with Posix extensions in general (like  
strptime() that triggered this). I think we need to setup some  
guidelines how to use them:

1) you must check if the function is available (use AC_CHECK_FUNCS or  
equivalent) in order not to break building on systems that don't have it

2) you must not use them in essential parts of the code, so not having  
them should only result in a reduced function set (not a useless  
program)

Only if a C replacement is provided which may be used if built-in  
support is unavailable (like we do for snprintf() for example), the  
above doesn't apply.

[...]

> if AC_USE_SYSTEM_EXTENSIONS solves this issue, and general improve the
> system, then it's perfect.

It seems to do the job.

> it's also right that we have snapshots ([tarball] from the Buildbot)
> available beside of the SVN, so that's not an issue.
> @Charles: could we somehow make a stable permalink to the latest
> available tarball?

That would be neat.

Best regards, Arjen
-- 
Please keep list traffic on the list