🚀 go-pugleaf

Tristan Miller <psychonaut@nothingisreal.com> writes:

> SHORT STORY:  In addition to the standard Unix configure script, I want
> Autoconf/Automake to produce separate ready-to-use Makefiles and
> config.h files for use with popular Windows compilers, and then include
> these alternatives in my distribution.  Is this possible, and if so,
> how should I do it?
> 
> LONG STORY:  I've written some software packages for which I am now
> producing distributions with GNU Autoconf and Automake.  The packages
> are console applications written in more or less standard C and C++,
> and before I moved to Autotools there had been reports of successful
> compiles on Windows with Microsoft's Visual C++ compiler.  If possible,
> I'd like to ensure that the autoconfiscated distribution continues to
> compile under Windows without requiring the user to install additional
> software, such as Cygwin.  However, now that I am using Autotools, I
> have rewritten some of my code to use some basic preprocessor macros
> #defined by configure (PACKAGE, VERSION, PACKAGE_STRING, etc.).
> 
> Is it possible to use Autoconf and Automake to produce a config.h and
> Makefile for use with MSVC++ and its NMAKE utility?  How about for
> other popular Windows C and C++ compilers, like Borland?  That way
> maybe I can include in the distribution a default config.h for use with
> Windows (which I presume will be overwritten by Unix users running
> configure) and an alternative Makefile, (say, Makefile.w32).  Then I
> could revise the installation instructions so that they essentially
> say, "Unix users, do the standard ./configure;make;make install. 
> Windows users, import the Makefile.w32 file using whatever mechanism
> your IDE provides."
> 
> Is this dream realizable?  If so, how do I go about doing it, and are
> there any gotchas I should be aware of?

This doesn't make much sense.

The configure script "fills in the blanks" in config.h.in and
Makefile.in with values which are appropriate for the system on which
the script is run.

If the user isn't going to be running a configure script, they will be
using fixed versions of config.h and Makefile. So just create versions
of config.h and Makefile which are appropriate for a typical Windows
system.

IOW, autoconf doesn't help at all. This isn't a Windows issue; it
wouldn't help if you were trying to do this for Unix.

OTOH, this is an area where automake could be useful, but isn't
(because it only generates GNU Makefiles, not NMAKE Makefiles). At
least, not directly; you could use it to generate config.h.in and
Makefile.in, and then just edit these by hand to produce the
appropriate files.

This assumes that you have the requisite knowledge; e.g. whether all
of the various HAVE_xxx are true or false for Windows. After all, that
information has to come from somewhere, and it can't come from the
configure script (as it does on Unix) if you aren't running it.

-- 
Glynn Clements <glynn.clements@virgin.net>