On Wed, Apr 14, 2010 at 9:49 PM, NightStrike <[email protected]> wrote: > On Sat, Apr 10, 2010 at 9:46 PM, NightStrike <[email protected]> wrote: >> On Sat, Apr 10, 2010 at 9:43 PM, NightStrike <[email protected]> wrote: >>> Would it be out of the question to teach automake how to handle a def >>> file as a source file for a library? On windows platforms, we >>> typically do something like this after building the libx.a file: >>> >>> $triplet-dlltool -k --as=$triplet-as --output-lib=libx.a --def=x.def >>> --as-flags=$(ASFLAGS) >>> >>> I noticed that the --def option isn't documented, that I can see. >>> Maybe there's a newer option that I'm supposed to use (oops), but >>> that's the general idea. You do this right before AR and RANLIB. >>> What I do currently in my makefile is to override AR: >>> >>> lib64_libksuser_a_AR = $(DTLIB) -m i386:x86-64 --as-flags=--64; $(AR) >>> $(ARFLAGS) >>> >>> Where DTLIB is: >>> DTDEF=$(DLLTOOL) $(AM_DLLTOOLFLAGS) --def >>> DTLIB=$(DTDEF) $(top_srcdir)/`echo $@ | $(SED) 's|/lib|/|;s|\.a|.def|'` >>> AM_DLLTOOLFLAGS=$(dlltool_underscores) -k --as=$(AS) --output-lib $@ >>> >>> It seems like this could easily be handled by automake, though, if it >>> detected a .def file in the sources list (much like how it knows how >>> to handle .S for asm, for example). >>> >>> Is this possible? Is there anyone willing to do it? >>> >> >> Addendum: A big benefit for me (other than many other things) is that >> it lets automake handle figuring out dependencies. In my example, >> libx.a doesn't depend on x.def, and I don't know how to make it do so. >> > > Ping >
x2
