[PD-dev] symlinks render pdstring unbuildable on MinGW/Windows

[Hans-Christoph Steiner]

On Mar 5, 2009, at 5:22 PM, Bryan Jurish wrote:

> moin Hans,
>
> On 2009-03-05 21:33:36, Hans-Christoph Steiner <hans at 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 at 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 at ling.uni-potsdam.de      -Lubarsky's Law of Cybernetic  
> Entomology




----------------------------------------------------------------------------

                             kill your television