|From:||Brandon J. Van Every|
|Subject:||Re: [Chicken-users] CMake cygwin can't do -0|
|Date:||Wed, 02 Aug 2006 12:26:18 -0700|
|User-agent:||Thunderbird 22.214.171.124 (Windows/20060719)|
John Cowan wrote:
Brandon J. Van Every scripsit:If symlinks are supposed to work on your system, but don't, then I want to know why. If symlinks aren't supposed to work on my system, but do, I want to know why. Open source is about giving the right bug report to someone. Perhaps your method will prove to be a workaround for a symlink bug. If so, we'll use it, but it'll be marked as a workaround, to be changed or removed when things get better.But why symlinks at all? The files named "lib(u)chicken-0.dll.a" just aren't what *anyone* uses in Cygwin or otherwise, so there is no point in keeping them.
Because that's what CMake can currently build. The other way it can currently build things, is cygchicken.dll and libchicken.dll.a. In fact I think I will switch it to this, and make a symlink for cygchicken-0.dll. In either case, I suspect that inconsistency of names is dangerous for the build somehow. I do not at all like solutions that are getting rid of what CMake consistently built. I would like to know what's actually supposed to happen with ld.
Do the rename (i.e. copy+delete) to arrange for the file to have the correct name. FWIU, the next version of CMake will do the Right Thing on Cygwin: cygfoo-0.dll in $PREFIX/bin, libfoo.dll.a in $PREFIX/lib. That's what we should emulate.
Meaning CMake 2.6? Did you try CMake 2.5 in CVS or something? I filed a feature request about the asymmetrical naming yesterday, but I don't see any response comments on it.
I have a sinking feeling that all these approaches are going to prove to be wrong in the long run. That really, getting down to the level of ld is what's needed.*shrug* I'm not a big fan of "sinking feelings" without evidence.
Well, like I said, I'm in the middle of minimizing my environment. I have to do things like walk my dog and eat lunch.
This approach is very simple, no more of a kludge than what you have,
It changes the CMake generated output. I expect consequences for this, both in operation, builds, and successive installations when things change again.
and *works*, *works*, *works*.
At present, so does mine, on my box. I'm going to refrain from discussing this further until I've minimized my environment. Then we'll know whether my MinGW tools or Platform SDK was really doing the work.
Brandon Van Every
|[Prev in Thread]||Current Thread||[Next in Thread]|