That change uncovered that this package uses c.std=gnu99 which, naturally, cannot be satisfied by MSVC. So it would be helpful to fix this with a revision before the 0.17.0 release (in a few weeks).
As to how to fix this, I think it would be good to first understand whether the gnu part is actually necessary by trying to CI the package with c.std=99. If it runs out it's not necessary, then that's the fix. Of course, it's possible that the source code detects whether the GNU extensions are available and does something suboptimal if not, so it makes sense to also check the source code and upstream documentation.
If it turns out that gnu99 is necessary, then the correct way to do it is:
using c.guess
c.std = ($c.class == 'gcc' ? gnu99 : 99)
using c
In the upcoming
build2release (0.17.0) we have tightened thec.stdvalue check for MSVC. For details, see: https://github.com/build2/build2/issues/383That change uncovered that this package uses
c.std=gnu99which, naturally, cannot be satisfied by MSVC. So it would be helpful to fix this with a revision before the0.17.0release (in a few weeks).As to how to fix this, I think it would be good to first understand whether the
gnupart is actually necessary by trying to CI the package withc.std=99. If it runs out it's not necessary, then that's the fix. Of course, it's possible that the source code detects whether the GNU extensions are available and does something suboptimal if not, so it makes sense to also check the source code and upstream documentation.If it turns out that
gnu99is necessary, then the correct way to do it is: