Jean-Marc Lasgouttes wrote:
> Angus> No, I mean that we have a --with-qt-dir arguement that is
> Angus> understood by configure and that I use it. Note that QT_DIR is
> Angus> not the same as QTDIR which the Qt build system treats as
> Angus> "special".
>
> Is there a reason why you use QT_DIR instead of QTDIR?
If there was, then it is lost in the mists of time.
> Angus> All I'm trying to do is tell the build system that it should
> Angus> look for the Qt library/header files at
> Angus> J:\MinSYS\home\Angus\qt3\{lib,include}
>
> That's QTDIR.
>
> In configure script if for example your CC variable has some value
> when you run the script (even without passing CC=mycc on the command
> line), this value will be remembered later. Users can reasonably
> expect that this will be true with QTDIR too. So making this change
> would make the configure script more predictable (and incidentally
> remove a part of your command line).
If I understand correctly, the deprecated way to invoke configure is
CC=mycc configure
The modern recommendation is to invoke it as
configure CC=mycc
What you're suggesting with your "precious variables" is that
QTDIR,QTINC,QTLIB take on the same behaviour as CC, above, right? Ie, the
--with-qt-{dir,includes,libraries} options to configure would dissapear
and the user will be able to invoke configure as either
QTDIR=myqtdir configure
or
configure QTDIR=myqtdir
That may be a good use of your time, but I don't see it as vastly
important ;-)
In the same vein, I think that your suggestion to invoke configure as
configure PACKAGE=LyX
would be a better way to proceed than to use some magic hidden in the
middle of the configure script. However, whilst I like this suggestion of
yours, it doesn't work:
$ ../configure PACKAGE=LyX
$ grep 'PACKAGE ' src/config.h
#define PACKAGE "lyx"
> Angus> The present system works; why are you interested in changing it
> Angus> now? (Just before a release.)
> I am not trying to change it now.
Good!
--
Angus
