Re: Frameworks on windows.

[Matt Rice]

--- Alex Perez <address@hidden> wrote:

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

guess i should explain how frameworks work under nt
you had Library/Executables where all the real .dll's
were located, and in foo.framework/foo.lib which is
the "import lib" if thats it's called, the thing
linked against.. and foo.framework/Headers/...

imho, we've already lost the main benefit of
frameworks because with this sort of mechanism, they
are not self contained... 

that coupled with the fact that i try and stay real
far away from windows, i probably won't work on it
myself... though i don't really mind helping if
someone wants to step up...

I can't really comment on the "probably never will"
I only tried to get the patches into libc cvs...
as without the libc stuff gcc/binutils patches arent
of much use on linux/hurd... anyhow there's no use in
it on windows, as the libc stuff is ELF specific...
mingw most likely already has patches to gcc/binutils
which are required to compile it, so 
its theoretically possible if it fails to make it all
the way upstream one could coordinate something with
those guys

so on windows we just need to add the "Libraries"
directories to the path, and  add -F and -framework to
gcc/binutils, my patches should be some help with
this... 

anyhow i strongly recommend that anyone, before
starting a campaign to get these patches upstream
(specifically the libc stuff) take a long look through
the archives... I honestly believe that any effort
spent would be futile, and could be better put twords
a patched up distribution... anyhow kinda off topic.

anyhow yet another way we could implement frameworks
in windows :)

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


                
__________________________________ 
Discover Yahoo! 
Find restaurants, movies, travel and more fun for the weekend. Check it out! 
http://discover.yahoo.com/weekend.html