moin Hans,
On 2009-03-04 05:37:40, Hans-Christoph Steiner hans@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 ;-)