On Mar 5, 2009, at 5:22 PM, Bryan Jurish wrote: > moin Hans, > > On 2009-03-05 21:33:36, Hans-Christoph Steiner <[email protected]> > appears to > have written: >> On Mar 4, 2009, at 4:23 PM, Bryan Jurish wrote: >>> 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 > > argh. these are svn:special links. > > Just so I understand, what form does the "huge wrench" take? Does the > whole auto-build fail, or just the moocow/ packages? > >> 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. > > agreed. > >> 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. > > the rsync "-L" flag ("--copy-links") works for me here, even with a > preceding "-a" ("--archive")... does that not work on cygwin? The > only > times I've ever had problems with "-L" were symlink cycles (./dir - > > .), > which I certainly am not inserting into the repository. > >> So basically, moocow is the only build system included in Pd-extended >> that relies on symlinks, > > ok. > >> so I am guessing the easiest path forward is >> to not use symlinks or not support Windows. > > I'm not convinced. > >>>> 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 > [snip] >> >> With makefiles you can use "include" instead of symlinks, so I am >> sure >> that automake has a similar functionality. > > Again: of course it does. Actually, I find the suggestion that I > might > not have though of this mildly insulting. I don't think it was > meant to > be; guess I'm just a bit peevish today. Sorry. > >> You could make >> pdexternal.am just a file that includes the common file, and nothing >> else. > > Yes I could, but it wouldn't solve anything. > > I realize you probably don't really care about the details of my build > subsystem, but please try to understand at least this much: as soon > as I > "include ../common/pdexternal.am" (regardless of whether that > happens in > ./Makefile.am or ./pdexternal.am), I no longer have a self-contained > and > independent package. > > Same goes for the "-I m4" (rsp. "-I ../common/m4") option to > aclocal, as > declared in Makefile.am. Try this, and automake's 'distcheck' target > explodes, and the 'dist' target produces a package which is incomplete > (doesn't contain anything from ../common and cannot be used for > further > autotools-sensitive development without that code). So it's not as > simple as "include", given my desire to continue to maintain > self-contained and independent packages (in addition to supporting the > pd-extended build system). > > Possibilities I see, all of which are unsatisfying in one way or > another: > > I could svn-copy the "common" stuff into each and every > quasi-independent external package that uses it, but that results in > precisely the kind of maintainance snafu I wrote pdexternal.am & co to > avoid, since changes in ../common/x then wouldn't get propagated > to ./x > without another explicit SVN copy operation to each package dir > "." ... > unsatisfying. Essentially the same applies to multiple copies of the > common code within SVN, which is even uglier (for SVN itself). > > Re make: I can't even write (standard package-local ./Makefile) make > targets for the 'common' stuff, because much of it is m4 and automake > code, which needs to be present before ./configure gets generated, > which > needs to happen before ./configure can run, which needs to happen > before > 'make' has a makefile to work from. I could write a kludgy script or > another "Makefile.svn" for each package dir to handle this, or maybe I > could do the copying from moocow/extended/Makefile, which handles my > other pd-extended build kludges, but in all cases I lose package > independence at the SVN level (as well as a chunk of maintainability, > since I need a separate kludge for each package, unless the kludge > itself is shared, in which case we're right back where we started), > which is also unsatisfying, since it keeps the "sharedness" of the > common code out of SVN entirely, and pure SVN builds of single > packages > would require at least ../common (and maybe ../extended), as well as > additional black magic calls to "make -C ../extended ..." rsp "make -f > Makefile.svn ..." rsp "./prepare-svn.sh" ... This may be the best way > to do it, ugly though it is. I'll think about it some more. > > ... so basically, if you can make this tangle go away by adding > another > flag to your rsync call, I'd be really grateful.
Sorry, I had no intention to insult or demean, I guess I was just terse. The bad news is that its not that simple. I added "--no-l -- copy-links" to cygwin rsync and it still doesn't work. There is nothing you have to do here, I just thought it'd be nice to have those externals included in Windows. Here are the logs, it seems it doesn't find the compiler properly: http://bxmc.poly.edu/pdlab/moocow_log.txt http://bxmc.poly.edu/pdlab/config.log What I don't understand is why this code needs such a complicated build system? As far as I can tell, it is mostly pretty standard C code. I find that in the long run, simple Makefiles are the least work overall. To each his own, I suppose, or maybe I'm missing something. .hc > > > marmosets, > Bryan > > -- > Bryan Jurish "There is *always* one more > bug." > [email protected] -Lubarsky's Law of Cybernetic > Entomology ---------------------------------------------------------------------------- kill your television _______________________________________________ Pd-dev mailing list [email protected] http://lists.puredata.info/listinfo/pd-dev
