Re: Frameworks on windows.

[Alex Perez]

David Ayers wrote:
> 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.

Yes, but that is a tool-level problem. There is only one tool I know of 
that allows you to make true NTFS symbolic links and hard links, and it 
is not part of any other project. The bigger problem is that, after you 
create the symlinks in Windows, Windows Explorer does not represent them 
different from normal file folders, and if you delete a windows symlink, 
it also deletes the target, even though it IS a real symlink (not a hard 
link). This is simply poor windows explorer behavior, but its a 
potential problem.

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

Well, I think we just need to make it heard that we want such 
functionality. Currently, the developers dont think anyone wants it, and 
probably think Matt is just some crazy guy, which he is indeed not.
> 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.

Yes. Warning: The term Junction is not the correct term, and 
windows'/microsoft terminology for symlinks and hard links are known to 
be internally inconsistant within their own documentation.
> > > 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.

Yes, it could, but...
> > > 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.

I agree, real windows framework support would be nice.
> Cheers,
> David