On 8/18/17 10:27 PM, Eli Zaretskii wrote:
Cc: Eli Zaretskii <[email protected]>
From: Pekka Seppänen <[email protected]>
Date: Fri, 18 Aug 2017 19:25:35 +0300
To summarize, in the future, I'd like to be able to build a shared DLL
library for GNU Make (on msys, on msys-mingw, on mingw, or whatever
POSIX alike layer runs on a native Windows). It is techinically
possible, but the only thing currently lacking is that either a)
libgnumake-1.dll.a is not built, b) nor it doesn't end up in the binary
distribution, unless the binary distributer happens to manually
copy/install that file.
Installing Windows import libraries is commonplace in GNU projects,
and yet I never saw those projects using WINDOWSENV or similar
tricks. All we need is add a variable that would be mpty on other
systems and libgnumake-$(VERSION).dll on MS-Windows.
IOW, I still don't understand why would we need to do this the way you
suggest, if all that's missing is commands to install the import
library.
It was just a proposal, I don't really care if that exact patch ends up
anywhere, just the result what the patch tries to do. Maybe there's a
more clever way to do that than what I ended up with -- anyway, should
be doable.
Currently, the import library does not get built unless the code is
targetted for a native Win32 host, in a sense that the host implements
the full Win32 API, i.e. _WIN32 et. al. is defined. While (msys-)mingw
does this (more or less), msys in this case doesn't. So one can't simply
forcefully whack in _WIN32 macros and expect things to work on msys, as
it's really more like cygwin -- POSIX on Win32, except that doesn't
require an external [cygwin] DLL (and has a bit more relaxed path
handing; the two main reasons why I prefer it).
So, if one does disambiguate these two cases; a fully compliant native
Win32 build and a build for a native Win32 system (in this case one only
needs the dynamic loading stuff, basically all handled by modern
compilers under the hood), one gets two birds with one stone. So, on
msys-mingw/mingw one would need to have __declspec(dllimport/export) AND
win32/ objects, but on msys only the dllimport/export stuff. With the
current way it's done by just checking for _WIN32 etc. macros (in
intmake.h and gnumake.h) making a different between these two cases is
not possible.
I guess what I'm trying to say here, is that all (ok, perhaps not all,
e.g. cygwin) Win32 builds should end up with GMK_EXPORT having the
suitable __declspec defined and -Wl,--out-implib given for the linker,
but not necessarily having all the other Win32 stuff being pulled. I
hope this is starting to make some sense?
-- Pekka
_______________________________________________
Bug-make mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/bug-make
