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.
I think the build system should create the links using $(LN_S). That 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.
.hc
-----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.
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)
mgasdr IOhannes
[1] http://subversion.apache.org/faq.html#symlinks
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 09/30/2011 05:17 PM, Hans-Christoph Steiner wrote:
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.
afaik, managing symlinks in SVN is fully possible if you want to target "windows" (proper), as you will then get copies of the files (no symlinks, no shortcuts, no emulations), which is what i expected and which would have done no harm.
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.
well, i guess that with this constraint, managing symlinks in SVN is consistent on each platform as well. afaik, mixing mingw and cygwin is to be considered "across platforms", which is where our problems come from (because the checkouts (including symlinks) where done with cygwin and the builds done with mingw (not knowing how to handle cygwin's symlinks)
anyhow, nevermind.
fgmasdr IOhannes
-
Hans-Christoph Steiner -
IOhannes m zmölnig