On Fri, 2011-09-30 at 17:07 +0200, IOhannes m zmölnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 09/30/2011 04:50 PM, Hans-Christoph Steiner wrote:
Now I see the root of the unfold-help.pd issue, zexy relies on symlinks that are checked into svn. That'll work fine on UNIX, but is very unpredictable in Windows. For example, a Windows svn client might check them out by copying them. A cygwin svn client might check them out directly, but then cygwin has its own symlink format which is compatible with Windows shortcuts. Then MinGW does not have a native SVN client packaged, so if you will get different results depending on whether you use a Windows or Cygwin svn client in MinGW.
which is arguably a "bug" in cygwin... i was relying on the svn documentation [1] that claimed that on "windows" syminks would be checked out as (copy) files.
Cygwin symlinks are not Windows shortcuts. And Windows does not have symlinks (shortcuts != symlink). Cygwin symlinks are somewhat compatible with Windows shortcuts and behave fully like symlinks when you're in Cygwin. And Cygwin is not Windows, its really its own platform. I'm not sure how Cygwin's svn handles symlinks, all I am saying is that managing symlinks in SVN is not really useable if you want to target Cygwin and/or Windows.
I think the build system should create the links using $(LN_S). That
i switched the build-system to that after i gt your original email about "unfold".
will work in a consistent fashion in all of the above situations. On Windows/MinGW, it'll always copy, on Cygwin it'll make the special Cygwin symlinks, and on UNIX it'll make standard symlinks.
how is this "consistent fashion"? it will hopefully get us working with the current setup on your build machines, but will break for cygwin compilations (if i understand your explanations correctly)
It is consistent on each platform, i.e. MinGW builds will be the same no matter how they were checked out. Its definitely not consistent across platform.
.hc