On 7/23/2012 1:32 PM, Akira TAGOH wrote:
I don't see any error on Linux say... ln is capable to create a broken symlink (at that point) but it could be valid later.
Oh. I was not aware of that. Assuming then that the files in question get put there later, then it would work, right? I think I might know then why this doesn't work with mingw on Windows. As far as I know, when using mingw/msys on windows, the ln can't create symbolic links since that is something Windows doesn't understand. I believe that it just does a copy instead which would mean that this anticipation type link won't work because you can't copy a file that doesn't exist, right?
Anyway, on git master, installing config files happens earlier than creating symlinks now. it should works for you. try it.
fascinating. I will try it.
Yes. it's intentional, because those symlinks are referring from the installed config files. otherwise all of users has to install the source code too.
Ok, I think I understand all this. So, the question that remains is this: how can the code be fixed so that those files exist before making a symlink such that it won't break on Windows?
Well, difference between 2.9 and 2.10 is whether the source place of ln is the relative path or the absolute path. no changes in the
but regardless of relative or absolute, if the source doesn't exist, then a copy would break, right?
installation order. so any config files shouldn't be there at that time. but your ln didn't just complain that for the relative path I guess.
I don't totally understand the differences between 2.9.0 and 2.10.0 but I do know that 2.9.0 installed without this problem. I know I could be wrong but it seems to me that the order must have been different if this worked on windows. Damon Register _______________________________________________ Fontconfig mailing list Fontconfig@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/fontconfig
