[Gdal-dev] nmake.opt

[Simon Perkins]

On Fri, 2003-07-18 at 14:22, Andrey Kiselev wrote:
> Simon,
> 
> Did you note, that current configure script is 7316 lines long and
> written in shell language, which is much more feature rich than Windows
> cmd? I think writing similar tools for Windows will be a big pain.
> 
> Besides of this, you will need to scan all directories to find where is
> libraries installed, because there is no predefined places in Windows
> environment. And you should run a set of tests in every place, where
> you found library, which looks like what you need. All of this will take
> a long time without warranty that you really found the right library
> installation.

All good points, and I certainly don't intend to reproduce all of
autoconf/configure's capabilities. Automatic library/program detection
is definitely out, at least for a first stab. My principle aim is just
to make nmake.opt work better with CVS and so I think something simpler
will suffice.

At the simplest level, win-config could be just a script that copies
nmake.opt.in to nmake.opt, and fills in the blanks with fixed default
values. The user then edits nmake.opt as they see fit. You would only
ever run a win-config like this once, just after checking out the code,
since running win-config again would reset your configuration.

More complex, and probably the level I'll aim for, is where the
win-config script looks at the previously generated nmake.opt and uses
the values filled in there as defaults for filling in the blanks, when
copying from nmake.opt.in to nmake.opt. This win-config could be run as
many times as you like without destroying your existing configuration.
In addition, if changes are made to the nmake.opt.in template, these
changes will be merged into the existing nmake.opt.

Does that sound more feasible?

As far as I can see, the main issue with this approach is that there is
no interpreted scripting language that comes standard with windows that
is more powerful than cmd.exe. So win-config would probably have to be a
compiled, say C, program itself. So I'd probably add two files to CVS:
win-config.c and make-win-config, which is just a bat file that compiles
winconfig.c to win-config.exe. For simplicitly, we could also check thet
win-config.exe script into CVS as a binary file as well.


Then the windows build process would amount to:

- After checking out the code for the first time ever:

> make-win-config  (optional if we stick win-config.exe in CVS)

edit nmake.opt if required.


- After each cvs update:

> win-config

edit nmake.opt if required (usually not necessary)


- Every time you build:

> make /f makefile.vc

as usual...



Sy