Hi Bob, * Bob Rossi wrote on Thu, Mar 27, 2008 at 06:55:26PM CET: > On Wed, Mar 26, 2008 at 03:28:26PM -0400, Bob Rossi wrote: > > > > I want to install mingwm10.dll, since my program requires it. I'm trying > > to figure out the best way to do this. The dll lives in /c/mingw/bin. > > > > Would > > bin_DATA=/c/mingw/bin/mingwm10.dll > > make the most sense? Any suggestions?
> I switched over to linux, and got an example to work like this, > bin_SCRIPTS = /usr/lib/libglib-2.0.so > Is this a stupid thing to do? Erm, yes. Even apart from the fact that such a hard-coded path is pretty unportable. > Is there a better solution? I'm not sure what you want to do. You want make install to copy /c/mingw/bin/mingwm10.dll to /usr/local/bin/mingwm10.dll? Why in the world would you want to do that? And if you really want to copy that file somewhere, why do you not just keep it as part of your distribution tarball? And yes, apart from it looking like a weird thing to try in the first place, here's a bunch more reasons against the above: - on my w32 system, mingwm10.dll lives in another place (in fact, it happens not to, but it easily could), - on my GNU/Linux, the library does not exist, but there is an import library libmingw32.a which I think can be linked against, - *_DATA does not set execute permissions on installed files (I think this is less of a problem for w32 than for unixes, but may still be for cross compilation?), - *_SCRIPTS are installed after *_PROGRAMS are installed (or even concurrently with parallel make), so if a program needs the freshly installed library, that can break, - install-strip won't work on that library. I agree that Automake does not provide a good method, only relying on documented interfaces, which can overcome all these issues. Cheers, Ralf
