> 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 > *) 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. > > 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. > > 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?
I think anything working would be an excellent start :-) ... I agree with a practical approach where we look for something working and robust ... even if it turns out not to be elegant and might miss a bit of functionality (eg, versioning). :-) ... Probably even just replacing all the symlinks with full copies would be OK as a start if we get a working system. Then I suppose the next step is trying to avoid copying everything multiple times ... probably the only way to achieve that is to remove less used functionality (eg removing versioning as you say). ... btw for the framework's own headers before installation ... I'm tempted to suggest something but I really think I'd need to look at the code before speaking ... So please go ahead! If you do a first working implementation, then -- even if details get changed later -- it should get the process started ... ... I'll happily fire up my Windows and review (and potentially rewrite/extend) a working implementation ... Thanks! :-) _______________________________________________ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev