On 12/14/2011 04:49 PM, Adrien wrote:
Hmmm, right. But if /usr/bin/gcc is already a symlink, ocaml wouldn't be able to use it at all... I find it quite weird but I don't have a cygwin box to test.
Well, that's precisely the point: the natural way to use gcc 3 under Cygwin is through symlinks in order to have /usr/bin/gcc links to gcc-3.exe. But then ocamlopt and flexlink cannot see it. A solution would have been to have them look directly for gcc-3.exe (and to fix the change of path for /lib/mingw), but we decided to use this opportunity to switch to gcc 4.
But windows actually has symlinks. Kind of. Starting with Vista and the corresponding NTFS version. But by default you need to be an administrator to use them, you can only create a limited number of symlink in a given folder afaiu, some functions work on the symlink and some on the target (stat()/lstat()). They have a number of limitations and last time I looked at them, I found them to be mostly unusable because of their limitations. They're one quite big issue I've had for packages on windows: if I cross-compile a library from Linux, and make a tarball which has a number of symlink in it. What to do when untarring on windows? Try to create symlinks? Use hardlinks when possible? Copy the file's contents? Something else?
Even if Windows supports kinds of symlink internally, this is a rarely used/exposed features. I think it's a bad idea to rely on them for a packaging system (targeted to "native" Windows users). They would look "foreign" to users, and we should expect a lot of bad support from existing tools.
Alain -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
