On 01Jun2019 07:18, Kevin J. McCarthy <ke...@8t8.us> wrote:
On Sat, Jun 01, 2019 at 04:36:38PM +1000, Cameron Simpson wrote:
If I were writing the conjectured goal above I'd probably do this:

mutt_version='#define MUTT_VERSION "'`sh "$(srcdir)/version.sh`'"'
version_h=`[ -s version.h ] && cat version.h`
[ "$$mutt_version" = "$$version_h" ] || echo "$$mutt_version" >version.h

in "configure", not in the Makefile. As a prebuilt step. Once you've got a version.h you're good.

:-) Funnily enough that's the way it was in the first place.

Hah.

But as Vincent mentioned, the change was to save developers from having to reconfigure all the time just to bump the version number.

That wasn't apparent to me before. I still think there's a case for putting it in "make clean". Though that again will cause a complete rebuild. Though it skips configure.

But I think what I'd really want is:

version.h: $(srcdir)/version.sh
 echo '#define MUTT_VERSION "'`sh '$?'`'"' >'$@'

Why _don't_ we just have this?

I'm not a Makefile person myself. My "fix" added the version.sh prerequisite and appended to the version.h explicitly just to match the target below, reldate.h.

If there is something to be gained by using the Makefile variables I'm all ears, but personally I find the recipe less readable with that way.

The only thing gained from using $? and $@ is that renaming the target or prerequisite doesn't require matching adjustment of the recipe. But the recipe is very small and I agree it is less readable with $? and $@.

Cheers,
Cameron Simpson <c...@cskk.id.au>

Reply via email to