#freebsd
#freebsd@lobocode @meena Regarding Mina's "make" commit, I'd have remarks 馃槈 :
- POSIX make is IMHO too limited to use for anything "non-trivial" in any other way than *generate* the makefiles with more powerful tools. For hand-written makefiles, GNU make isn't the worst choice when portability is a goal ... it's available on many platforms.
- I agree recording dependencies would make sense.
- Here we talk about a tool specifically for #FreeBSD. Does it make any sense to design the build in a "portable" way? If not, I'd suggest using FreeBSD's make (bmake) together with FreeBSD's make framework from /usr/share/mk ... this will simplify things a lot. I could create a PR doing that if you want.
@lobocode @meena
PR created: https://github.com/scovl/checkrc/pull/5
Mina, no, not "just your headache", the portable subset of make simply doesn't cut it, and doing complex things in make is possible, but hard and quickly becomes unreadable, that's why well-written frameworks are a nice thing ...
I personally have my very own for #gmake (which I use for all portable stuff). When writing stuff specifically for #FreeBSD, I very much prefer using what's already there.
@lobocode @meena BTW, there are a few things you might want to change, but that's up to you to decide:
- I don't think you use any "newer" C features, so CSTD=c11 or maybe even CSTD=c99 might be enough
- -pedantic *can* cause issues, although it currently probably doesn't, you *might* want to remove it
- bsd.prog.mk defaults to building debugging info into a separate file and also install that. If you don't want that, you *might* want to add MK_DEBUG_FILES=no
@lobocode @meena Found another issue and created yet another PR for it:
https://github.com/scovl/checkrc/pull/7
Background is explained there, in a nutshell, avoid setting -Werror in the default CFLAGS (distributed to users), it has the potential to just break builds...
Instead take advantage of github's infrastructure and have a CI build run automatically on pushes and pull requests that *does* use -Werror.
@lobocode @meena NP. You could now even get creative and e.g. add testcases (rc.conf files with different errors) in '.github' and script in the yaml file to check for the expected output or whatever.
But OTOH, I wouldn't invest TOO much work here either, because this part is strictly tied to github and services *they* offer (while a git repository itself is completely independent from where it is hosted).