Re: Frameworks on windows.

[David Ayers]

Alex Perez wrote:
> 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.

But IIRC one cannot simply rm/del a symlink/junction (well, not without
recursively deleting the contents or using a custom command).  This
makes the usage of this mechanism rather dangerous, but indeed it should
be possible if some tool is supplied which -make could use.

>> *) 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.

Frameworks (or true frameworks as some people call them) currently only
work on Darwin (and for Matt Rice ;-) ).  Matt has a set of patches that
actually add framework support to glibc, binutils and gcc for gnu-linux
(and possibly gnu-hurd).  He has tried integrating them upstream but has
not received any response from glibc maintainers, and anyone following
the general argumentation on new features of the main maintainers,
probably has to admit that framework support "probably never will" be
integrated into glibc.

OTOH, similar to the workarounds we have in -make for frameworks on
non-Darwin systems, we could probably make it work in conjunction with
Free versions of junction command line tools.  But understand this is
not the relocatable framework which compiler/linker/loader handle via
-F/-framework.  And windows users must be educated to not attempt to
remove symlinked/junctioned directories via standard tools like rm, del
or the Explorer.

>>  
>> 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.

Actually in frameworks that's not where headers go.  They actually do go
into 'Foo.framework/Headers/filename.h'.  The fact that you
#include/#import them via <Foo/filename.h> is a gcc (i.e. preprocessor)
modification by NeXT/Apple on OPENSTEP/Darwin systems.  On OPENSTEP for
NT they used a similar technique as you did.  Like you mentioned on
non-Darwin system -make uses symlinks from the Library/Headers
directory.  I suppose this could also be done with the junction tools.

>> If I send in a patch to do the above, in theory, would it be acceptable?

I am not a -make "maintainer" so this is in no way meant to sound
authoritative.  Yet in my opinion it would be better if someone could
contribute command line tools to handle junctions(symlinks) on windows
(possibly even integrate them upstream into cygwin and mingw) and base a
-make patch on those which attempts to simulate frameworks there, as we
do on all other non-Darwin platforms.

Cheers,
David