One solution is to create a new file with the correct timestamp, that is either a copy of the existing spec file or a new generated one.
ok, here's an idea that i'd be grateful if i could bounce off of you:
what if i make the .spec generation a standalone operation that needs to be explicitly run by the library author? it's a bit more burden for the lib author because he needs to keep track of changes to the configuration and/or the .h file, but that would implicitly fix one of the bugs.
in fact i have already pushed this change:
https://github.com/cffi/cffi/commit/d59331b050fb31f3a3f9103f302890be176b77ce
and shall i do the same with the next stage, namely the .lisp file generation? for some reason i think it's better to keep that automatic and integrated into the normal flow of the build process, but i'm not fully convinced about that either.
if i did that, it would annull the last remaining issue, namely the current unlucky
(load-op ,(find-system "cffi/c2ffi-generator"))
dependency.
but the price would be high: either users would need to regenerate .lisp files by hand each time they pull changes to the .spec file (this is unacceptable), or all libs would need to check in also the generated .lisp files into their repos (this is less of a constraint/burden, but still...).
any thoughts?