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
_______________________________________________
Gnustep-dev mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/gnustep-dev
