[PD-dev] symlinks render pdstring unbuildable on MinGW/Windows
Bryan Jurish
moocow at ling.uni-potsdam.de
Wed Mar 4 22:23:16 CET 2009
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?
do have an error message or a make log or a config.log for me?
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?) ?
> 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...
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
More information about the Pd-dev
mailing list