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

[Charles Wilson]

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