[PD-dev] symlinks render pdstring unbuildable on MinGW/Windows

Hans-Christoph Steiner hans at eds.org
Thu Mar 5 21:33:36 CET 2009


On Mar 4, 2009, at 4:23 PM, Bryan Jurish wrote:

> moin Hans,
>
> On 2009-03-04 05:37:40, Hans-Christoph Steiner <hans at eds.org>  
> appears to
> have written:
>> I was just trying to build string2any and friends on Windows for a
>> student, but the symlinks used in moocow are throwing a huge wrench  
>> in
>> the process.
>> They show up at .lnk files, and are not links at all.
>> That's because cygwin translates symlinks into Windows shortcuts,
>> aka .lnk.  So symlinks will never work on Windows.
>
> uh, *which* symlinks exactly are you referring to?

trunk/externals/moocow/pdstring/m4
trunk/externals/moocow/pdstring/pdexternal.am

> do have an error message or a make log or a config.log for me?

I am working on getting the Windows build server  up, not quite there  
yet, almost.  Then I can give you shell access.

> SVN can handle symlinks with the "svn:special" property, and according
> to the Subversion FAQ (http://subversion.tigris.org/ 
> faq.html#symlinks):
>
> "the Subversion repository has no internal concept of a symlink. It
> stores a "versioned symlink" as an ordinary file with an 'svn:special'
> property attached. The svn client (on unix) sees the property and
> translates the file into a symlink in the working copy. Win32 has no
> symlinks, so a win32 client won't do any such translation: the object
> appears as a normal file."
>
> The most recent SVN book says much the same about svn:special  
> symlinks.
>
> ... so I wonder how you managed to get .lnk files out of svn at all,  
> if
> indeed that is what's happening...
>
> ... or am I creating symlinks somewhere with AC_CONFIG_LINK?  I don't
> think I am anymore (but I'll check), and even that should default to
> something safe on the configuring system (copy for win32, according to
> the autoconf docs), so I don't really know what is going wrong where.
>
> [grep -r AC_CONFIG_LINKS pdstring/*]
> pdstring/configure.ac:AC_CONFIG_LINKS([src/any2string-help.pd:src/ 
> any2bytes-help.pd])
> pdstring/configure.ac:AC_CONFIG_LINKS([src/string2any-help.pd:src/ 
> bytes2any-help.pd])
>
> ... oops: ok, I guess I am calling AC_CONFIG_LINKS() too (therefore  
> the
> behavior sounds like a bug in cygwin, but that's beside the point I
> guess) -- this would be easy to replace e.g. with svn:special symlinks
> (preferred) or an automake install-local target or whatever, but I  
> still
> need to know if any of the svn:special symlinks are exploding on you  
> as
> well (e.g. pdstring/m4, pdstring/pdexternal.am,
> pdstring/src/mooPdUtils.h)...
>
> If the svn:special symlinks are going sour, maybe you should try a
> different svn client?  If AC_CONFIG_LINKS() is exploding, then maybe  
> you
> need to run ./configure in a different shell environment (MSYS?) ?

The whole thing is run in MSYS/MinGW except for the rsync, which is  
run in Cygwin.  Running rsync in MSYS did not work for me, I could not  
get it going, no matter how hard I tried.  Most of it ran, but there  
were some technical details which I forget.  Basically, dealing with  
Windows is a massive pain in the butt.

The other thing is that the new code is actually copied to the build  
server using rsync rather than svn.  rsync has the very handy "-- 
delete" feature, meaning rsyncing leaves you with a perfect recreation  
of the original with the additions and subtractions.  That would not  
be easy to do with svn and "make clean".  Unfortunately, rsync is very  
aware of symlinks.  I tried to make it copy the symlinks target  
instead, but that didn't work.

So basically, moocow is the only build system included in Pd-extended  
that relies on symlinks, so I am guessing the easiest path forward is  
to not use symlinks or not support Windows.

>> Instead of using symlinks, the build system should just use the paths
>> to the shared files.  I don't know automake, but that is possible  
>> with
>> other build tools, so it seems likely to work there too.
>
> I understand your concerns, and I do wish my externals to remain
> compatible with pd-extended builds even on (shudder) windoof.
>
> And yes, of course referencing paths outside the project root  
> directory
> is possible with automake.  My issues are not with the possibility
> (heck, it's *possible* to write a C compiler entirely in DOS .BAT, but
> who would want to?), but rather portability and ease of  
> maintainability
> (i.e. I'm lazy).
>
> Unfortunately, I don't see any good way to keep my code centralized
> *and* still maintain independent self-contained external packages  
> which
> play (mostly) nicely together with the pd-extended build system
> *without* using either svn:special symlinks or svn:externals
> (repository-internally, but still svn:externals, which I seem to  
> recall
> has been deprecated for use with pd-extended auto-builds), unless I
> create a second copy of each external package in the repository for
> pd-extended builds, which contains copies of all shared code (and all
> other code), and which has to be explicitly "published", rather than
> built from the straight SVN sources I use.
>
> I suppose the SVN catch-phrase "copies are cheap" could seem to  
> suggest
> just such a solution, but it strikes me as kludgy... then again,
> checking autotools-generated files (configure, Makefile.in) into SVN
> strikes me as kludgy too, and I'm already doing that, so maybe I  
> should
> just bite the bullet...

With makefiles you can use "include" instead of symlinks, so I am sure  
that automake has a similar functionality.  You could make  
pdexternal.am just a file that includes the common file, and nothing  
else.

.hc

>
>
> Thoughts, comments, criticism, & flames welcome ;-)
>
> marmosets,
> 	Bryan
>
> ps - it appears now that I've spent this whole evening I had planned  
> to
> use for working on utf-8 for pd-devel typing emails and wiki pages...
> maybe tomorrow ;-)
>
> -- 
> Bryan Jurish                           "There is *always* one more  
> bug."
> jurish at ling.uni-potsdam.de      -Lubarsky's Law of Cybernetic  
> Entomology



----------------------------------------------------------------------------

Man has survived hitherto because he was too ignorant to know how to  
realize his wishes.  Now that he can realize them, he must either  
change them, or perish.    -William Carlos Williams






More information about the Pd-dev mailing list