On Mar 5, 2009, at 5:22 PM, Bryan Jurish wrote:
moin Hans,
On 2009-03-05 21:33:36, Hans-Christoph Steiner hans@eds.org 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 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
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." jurish@ling.uni-potsdam.de -Lubarsky's Law of Cybernetic Entomology
----------------------------------------------------------------------------
kill your television