[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: defining make vars
From: |
Graham Percival |
Subject: |
Re: defining make vars |
Date: |
Tue, 8 Sep 2009 19:16:47 +0100 |
User-agent: |
Mutt/1.5.18 (2008-05-17) |
On Tue, Sep 08, 2009 at 11:50:09AM +0200, John Mandereau wrote:
> Hi guys,
> Le mardi 08 septembre 2009 à 10:13 +0100, Graham Percival a écrit :
> > > > I propose to extend /VERSION to include:
> > > > STABLE_VERSION
> > > > DEVEL_VERSION
> > - I'm asking if it's a good idea.
>
> This would be yet another incarnation of caching data from another
> branch in Git sources, so please no.
Mao.
> > > I suppose that we need STABLE_VERSION for producing the
> > > web site -- both the old lily-web and GUB scripts have/share
> > > code for deriving those from lilypond.org.
> >
> > Yes. We could still use those, but
> > - it require an active internet connection to build lilypond
> > (at least the first time). This seems like a Bad Idea (tm).
>
> Remember that building online web target is disabled by default, and the
> offline version of the web site (in top-build-dir/out-www/offline-root)
> will link to current version of the sources only.
Linking, yes, but we still want to list the version numbers.
> > - those scripts would need a bit of rewriting
>
> Yes, but this would not be so long or hard.
Who's going to do it?
> > - once rewritten, they'd add another bit to the complexity of the
> > build system.
>
> This will be false if we use cross-references that require xref-maps
> from the other branch to build the online web site. Anyway, this bit
> would be mainly isolated from the rest of the build system.
Err, what? I'm not talking about cross-refrences. I'm talking
about defining a
@versionStable = 2.12.2
@versionDevel = 2.13.3
so that the download links can be in the form
@uref{http://download.linuxaudio.org/lilypond/binaries/linux-x86/address@hidden,
(or possibly making a macro for the entire link, if we can't call
a macro from inside @uref )
Cheers,
- Graham
- defining make vars, Graham Percival, 2009/09/07
- Re: defining make vars, Reinhold Kainhofer, 2009/09/07
- Re: defining make vars, Jan Nieuwenhuizen, 2009/09/08
- Re: defining make vars, Graham Percival, 2009/09/08
- Re: defining make vars, Jan Nieuwenhuizen, 2009/09/08
- Re: defining make vars, Graham Percival, 2009/09/08
- Re: defining make vars, John Mandereau, 2009/09/08
- Re: defining make vars,
Graham Percival <=
- Re: defining make vars, Graham Percival, 2009/09/16
- Re: defining make vars, John Mandereau, 2009/09/16