gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Frameworks on windows.


From: Sheldon Gill
Subject: Re: Frameworks on windows.
Date: Wed, 29 Jun 2005 09:03:17 +0800
User-agent: Mozilla Thunderbird 1.0 (Windows/20041206)

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.


Interesting, what is the correct term?  I've seen the term junction:
http://support.microsoft.com/default.aspx?scid=kb;EN-US;q205524

and multiple other places:
http://www.google.com/search?hl=en&lr=&biw=819&q=junction+windows+NTFS&btnG=Search

The technical functionality used under windows is a "Reparse point". The details get somewhat messy.

Junction is the usual term for using the reparse point functionality to create a directory which points (path reparses) to another directory.

This gives a symlink to a directory. As far as I know, the link must be absolute. I'll experiment sometime to confirm that, but I'm 80% relative paths won't work.

Anyway, I don't think that trying to support symlinks under windows is the right way to go. For starters, you can't symlink to a file. Deletion is problematic.

Finally, it doesn't really help get the *real* functionality we're looking for. What we want is a single directory tree for the framework. That can be done without symlinks with the loss of versioning via symlinks. The ability to locate and load the framework code is key and can be done now that -base searches the framework paths properly. The next part is properly linking programs so they activate the framework location mechanism (NSBundle). That is gcc/binutils territory.


Regards,
Sheldon




reply via email to

[Prev in Thread] Current Thread [Next in Thread]