Den 2010-08-13 19:18 skrev Ralf Wildenhues:
> I would like to thank everyone who provided input on this topic.
> It certainly helps when considering where to go. One conclusion
> from this is that we should get Peter's MSVC support finished
> and completed for Automake 1.12 and the next Libtool release.
>
> I wasn't aware that there are more MSVC-related build system tools
> which one could target. I'm still not sure whether the idea to
> produce support for some of them should be buried completely, but
> I for one won't be pursuing it in the nearer future. If somebody
> else feels scratching that it however ...
>
> And of course I would be delighted if some of you provided fixes
> for pkg-config and whetever else is needed to make building for
> this setup work better.
Hi!
Sorry for the late reply.
A couple of things were never mentioned in this thread...
First I want to clarify that nmake support is not the same as
Visual Studio project file support. The project file can be used
to generate an nmake Makefile, but that is not "normal usage".
Normally you just load the project file into the GUI and go.
I don't know if there were anybody who had this wrong, I'm just
spelling it out just in case...
And second, in my opinion it is more important to not require
GNU binutils when using the MS toolchain, than to not require
a sensible make. We are almost there, but not completely. The
reasoning is that the make implementation should not affect the
end result, but mixing in tools from GNU binutils might. Most
of the remaining required uses of GNU binutils are not actually
doing anything to the binaries, they simply inspects them, but
one exception is the resource compiler.
This is an issue where automake could possibly help, since
Microsoft rc isn't really interface compatible with windres.
Microsoft rc produces a .res file, while GNU windres produces
a .obj (or .o) file. There's also the inevitable shuffle of
options... In a project of mine I have this in my
configure.ac:
AC_CHECK_TOOL(RC, windres,)
AC_ARG_VAR(RC, [Resource Compiler for Windows resources])
RC_VERSION
case $RC in
[[rR][cC]]*) msrc=yes ;;
*) msrc=no ;;
esac
AM_CONDITIONAL(HAVE_MSRC, test $msrc = yes)
And this in my Makefile.am:
if HAVE_WIN32RES
if HAVE_MSRC
foo_LDADD += foo.res
else
foo_LDADD += foo.$(OBJEXT)
endif
endif
if HAVE_MSRC
foo.res: foo.rc foo.ico src/resource.h
$(RC) -i $(top_srcdir)/src foo.rc
else
foo.o: foo.rc foo.ico src/resource.h
$(RC) --include-dir $(top_srcdir)/src foo.rc $@
foo.obj: foo.rc foo.ico src/resource.h
$(RC) --include-dir $(top_srcdir)/src foo.rc $@
endif
I would love to simplify that. I expect similar issues with
the message compiler (Microsoft mc vs. GNU windmc) but I haven't
needed a message compiler so I can't say...
Cheers,
Peter
