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

[Bryan Jurish]

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?

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

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

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

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