Greetings.

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?

Regards,
Tristan

--
_
_V.-o  Tristan Miller [en,(fr,de,ia)]  ><  Space is limited
/ |`-'  -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=  <>  In a haiku, so it's hard
(7_\\    http://www.nothingisreal.com/   ><  To finish what you

[ Post a follow-up to this message ]

> Greetings.
quote:

>
> 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?


mmh i'm fraid you'd need to have a sh interpreter on your winboxes to use th
e
./configure script... but then again, i might be wrong.. 

[ Post a follow-up to this message ]

Greetings.

In article <20031209162310.5e773665.paolino.gnu@disi.unige.it>, Paolo
Gianrossi wrote:
quote:
 
>
> mmh i'm fraid you'd need to have a sh interpreter on your winboxes to
> use the ./configure script... but then again, i might be wrong.. 


Read the long story version... I'm aware of this.  I'm not suggesting
that a Windows user execute the ./configure script; rather, I'm asking
if there's a way I as the package distributior can auto-generate
Windows NMAKE Makefiles to include in the distribution.

Regards,
Tristan

--
_
_V.-o  Tristan Miller [en,(fr,de,ia)]  ><  Space is limited
/ |`-'  -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=  <>  In a haiku, so it's hard
(7_\\    http://www.nothingisreal.com/   ><  To finish what you

[ Post a follow-up to this message ]

Tristan Miller <psychonaut@nothingisreal.com> writes:
quote:

> 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>

[ Post a follow-up to this message ]

Hi Tristan!

On 09 Dec 03 at 18:15, "Tristan" (Tristan Miller) wrote:

Tristan> Greetings.  In article
Tristan> <20031209162310.5e773665.paolino.gnu@disi.unige.it>, Paolo
Tristan> Gianrossi wrote:[QUOTE] 

Tristan> Read the long story version... I'm aware of this.  I'm not
Tristan> suggesting that a Windows user execute the ./configure script;
Tristan> rather, I'm asking if there's a way I as the package distributior
Tristan> can auto-generate Windows NMAKE Makefiles to include in the
Tristan> distribution.

You can supply set of ready-to-use files, Makefile.bcc, Makefile.m$vc, etc,
with paths and variables set to reasonable defaults. The user is then
expected to hack Makefile before the compilcation. You can look at
how PERL distribution does this.

--
Sincerely,
Dmitry

--- www.karasik.eu.org ---

He who dies with most the toys wins

[ Post a follow-up to this message ]

Greetings.

In article <84k752pcsb.fsf@raven.plab.ku.dk>, Dmitry Karasik wrote:
quote:

> You can supply set of ready-to-use files, Makefile.bcc, Makefile.m$vc,
> etc, with paths and variables set to reasonable defaults. The user is
> then expected to hack Makefile before the compilcation. You can look
> at how PERL distribution does this.


Yeah, this is what I was getting at... it's just that I was hoping the
Automake/Autoconf could generate these for me, since I have no idea
what the "reasonable defaults" are for standard Windows compilers, and
because Autoconf automatically #defines some constants (program name &
version) that vary from release to release (of my program) but not from
build system to build system.  I'll take a look at the Perl
distribution, though, as per your suggestion...

Regards,
Tristan

--
_
_V.-o  Tristan Miller [en,(fr,de,ia)]  ><  Space is limited
/ |`-'  -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=  <>  In a haiku, so it's hard
(7_\\    http://www.nothingisreal.com/   ><  To finish what you

[ Post a follow-up to this message ]