Re: defining make vars

[Graham Percival]

On Tue, Sep 08, 2009 at 09:36:22AM +0200, Jan Nieuwenhuizen wrote:
> Guys!  What happened to grep?

I had honestly completely forgotten that there was a make/ dir;
I'd been looking in stepmake/ and Documentation/.

> And common sense...?  this would mean that
> 
>   * it's hardcoded until you run configure -- you know that's not so
>   * it gets defined in config.make (as every configure
>     variable is) -- it is not

Good points.

> So...have a look at make/toplevel.make

Thanks!

> > I'm tempted to just dump the raw numbers into
> >   stepmake/stepmake/texinfo-rules.make
> 
> Good idea.  This will make everything easier.
>
> Our python build scripts even have hardcoded file and directory
> names -- names that even do not appear in any of the makefiles,
> because there they are wildcard-based :-(

I'd like to double-check this, since I'm manifestly not
comfortable with the build system, and we all tend to get quite
sarcastic when discussing it.  (which is great and funny as long
as you understand exactly when it's sarcasm and when it's not
sarcasm.  :)


I propose to extend /VERSION to include:
STABLE_VERSION
DEVEL_VERSION
I will adjust make/toplevel-version.make and
stepmake/stepmake/texinfo-rules.make accordingly.  We will then
have @versionStable and @versionDevel for the website.

(I might even separate those into STABLE_VERSION_OSX and the like.
Download links would be constructed from those macros)


Yes, this would mean that we store a few extra bytes that could
theoretically gather from git and/or a script like "make
update_versions" (from the current web/ branch), but I heartily
argue that the simplicity is well worth it.  Also, we need to
update /VERSION every time we make a release anyway, so there will
still only be one git commit (per release) concerning these
hard-coded values.  (err, I mean, this wouldn't involve additional
git commits that would clutter up the history, unless we made a
whole bunch of -1 -2 -3 releases)

Cheers,
- Graham