On Mar 4, 2009, at 4:23 PM, Bryan Jurish wrote:
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?
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@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