moin Hans,
On 2009-03-05 21:33:36, Hans-Christoph Steiner <h...@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 <h...@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.
marmosets,
Bryan
--
Bryan Jurish "There is *always* one more bug."
jur...@ling.uni-potsdam.de -Lubarsky's Law of Cybernetic Entomology
_______________________________________________
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
