This is the mail archive of the cygwin@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Solving the "relink exe's" libtool problem [take 2]


Alexandre Duret-Lutz wrote:

Any way lt-foo.c could go into .libs/?  Or just be erased after
foo.exe has been built?  Maybe both?
I see no problems with either or both...but I'd rather keep lt-foo.c around until 'make clean' (or libtool --mode=clean) time.

Also I if you don't move `foo' to `.libs/' I think you
should ensure that `libtool --mode=clean rm -f foo.exe' erases `foo'.
Good point. "libtool --mode=clean" won't currently get both of them. But automake's 'make clean' will (see below).

(Or does Cygwin's `rm' erase both at once?)
No, it doesn't.

Right now Automake doesn't use `--mode=clean'.  Maybe Automake
1.8 could start doing this so we don't have to hardcode this
sort of knowledge.
Yeah, I think this has come up before...

However, current automake "make clean" will at least attempt to delete all four of the following, whether they exist or not:
foo
foo.exe
.libs/foo (*)
.libs/foo.exe (*)
(*) by virtue of rm -rf'ing .libs

So, there's really no worry about cleaning up the shell wrapper or the "real" executable -- or the binary wrapper -- with present automake. But cleaning up the lt-foo.c file is an issue. I'd prefer to move it into .libs, but NOT erase it; automake's make clean will "get it" if it's in .libs (see rm -rf, above)

'Course, transitioning to libtool --mode=clean will mess that up, unless the problems you mention are addressed...

--Chuck


--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]