On Mar 4, 2009, at 4:23 PM, Bryan Jurish wrote: > 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?
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." > [email protected] -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 _______________________________________________ Pd-dev mailing list [email protected] http://lists.puredata.info/listinfo/pd-dev
