On Wed, Dec 22, 2010 at 07:29:13PM -0500, Richard Hipp wrote:
> I spent a very frustrating morning on Monday, downloading mingw and trying
> to get the makefile to work on a new windows7 box I have sitting off to
> might right.  It appears that getting the makefile to work on win7 will be
> very hard indeed.  If anybody has any hints, I would like to hear them.  At
> the moment, the only thing I can think to do is to completely rework the
> entire build process to not depend on standard unix tools like "make" and
> "awk" and "sed" since they just do not work or do not exist on
> mingw/windows7.
mingw is only about the toolchain, and you require more than that. MSYS is a
small collection of unix tools built with the mingw toolchain. They don't
coincide exactly with the current GNU unix tools, so its 'sed' will work a bit
different for example. They can be a bit special on the end of lines too
(CR/CRLF).
The MSYS prebuilt packages you may find can be very outdated. I don't know who
is responsible of maintaining that up to date.

What I'd do is to setup a cygwin environment, simply putting the MINGW toolchain
in the PATH variable previous to the rest of gnu cygwin pieces (its binutils,
gcc, ...), but make your program use the cygwin awk, cygwin sed, ... You can use
the GNU make coming with cygwin too. That will give you an OS environment very
much like what you would get in GNU/linux.

> I also have a brand new copy of VS2010 on my brand new win7 box.  Does
> anybody have any suggestions on how we might get VS2010 to compile Fossil?
> Recognize that (as with most of the software I write) the "source code" is
> not really C code, but rather text that looks a lot like C but which gets
> additional processing prior to being input to the C compiler.  In the case
> of Fossil, the "C-source-modules" are first processed by a program (source
> code included) called "mkindex", then another program called "translate",
> then a third program called "makeheaders".  Then there is an AWK script that
> runs to generate some additional header information.  Finally, the output of
> all of the above is ready to go into the C compiler.  But VS2010 seems to be
> of the opinion that all "source code" should be plain and simple C code (or
> C# or whatever) and not require any preprocessing by other utilities.

You can build fossil with any Express (free) edition of Visual Studio (with the
Visual C compiler). VS2010 Express is just fine.
It comes with a batch script that will put all its programs in the PATH. It also
puts an icon in "Programs" to start a CMD shell calling that batch script. From
that on, you have on PATH:
cl.exe - the compiler
link.exe - the linker

They require few parameters to go on, and if I recall correctly, with good
defaults. You have to learn how they generate ".obj" from ".c" ("cl file.c" may
be enough). And "link /output:fossil.exe a.obj b.obj ..." can also go on fine.

The MSVC tools come with 'nmake' (their implementation of 'make', with a syntax
slightly different than GNU make, but very close; but it does not like slashes
for paths, for example, iirc).
They come with 'vcbuild' (It can build vcproj files). 'vcproj' files are XML
descriptions on how to build ONE target from a group of source files. People
usually create it with the devenv.exe (the GUI frontend to all those things,
editor included).
They come also with 'msbuild', to build "solutions". Solutions group multiple
vcproj files (so multiple targets), so for example you can have a solution that
builds a Library and a Program linked to that library, whereas with 'vcproj
files' alone you would only be able to build one target.

If you want to use the MSVC compiler, I'd go with cygwin too. Then you have
gnumake, and other current gnu unix tools. Simply prepare your compiler
instructions to issue a "cl file.c /out:file.obj" or however that is done
instead of "gcc -c file.c", and you are done.

Personally, I barely use windows other than through cygwin's bash and rxvt or
sshd. Then I always prefer to have tools like 'fossil' built on cygwin instead
of raw Windows.

I may be able to answer in more detail, on questions about more detail.

Regards,
Lluís.
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Reply via email to