[PD-dev] symlinks render pdstring unbuildable on MinGW/Windows
Hans-Christoph Steiner
hans at eds.org
Thu Mar 5 21:33:36 CET 2009
On Mar 4, 2009, at 4:23 PM, Bryan Jurish wrote:
> moin Hans,
>
> 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
> 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."
> jurish at ling.uni-potsdam.de -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
More information about the Pd-dev
mailing list