moin Hans, On 2009-03-04 05:37:40, Hans-Christoph Steiner <[email protected]> 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." [email protected] -Lubarsky's Law of Cybernetic Entomology _______________________________________________ Pd-dev mailing list [email protected] http://lists.puredata.info/listinfo/pd-dev
