|
From: | Alex Perez |
Subject: | Re: Frameworks on windows. |
Date: | Mon, 27 Jun 2005 21:52:19 -0700 |
User-agent: | Mozilla Thunderbird 1.0.2 (Windows/20050317) |
Jeremy Bettis wrote:
Let me share a few ideas here before I send in a patch so I can judge the likelyhood of it being accepted. Assumptions:*) Frameworks depend heavily on symbolic links. (in gnustep-make) *) Windows (Mingw environment) has no symbolic links
You are misinformed. There is a lot of misinformation Re: symbolic and hard links under Windows. It only works when using NTFS under XP, however, which is where we start to have problems.
*) The Foo.framework/Versions/A/... is probably not worth supporting w/o symlinks. *) Gcc (non-apple) doesn't support the -F or -framework options, and on windows probably never will.
mmm, I disagree with the "probably never will" part, because it's possible to do, just difficult given the current mingw toolchain. I do however agree that frameworks under Windows currently don't really work.
So I have put in a number of ifeq($(HAS_LN_S),no) type statements into gnustep-make to have it simply not use the Versions stuff at all.
Cool.
Next problem, before installation, the framework can't find it's own headers, since again the ln -s ../Foo.framework/Headers derived_sources/Headers/Foo fails. I had a complex hack that generated an #include "../Foo.Frameworks/Headers/filename.h"for each file, but now I think a better idea would be to have the headers go into Foo.framework/Headers/Foo/filename.h right from the start. If I send in a patch to do the above, in theory, would it be acceptable?
One would hope so! Cheers, Alex Perez
[Prev in Thread] | Current Thread | [Next in Thread] |