2011/4/5 Arnaud Charlet <char...@adacore.com>: >> I agree, and I read the threads about that there on mingw.org. I >> don't see a good chance that it get fixed soon there. Nevertheless is >> the msys-environment the only way to do a full bootstrap of native gcc >> toolchain, so I would simply love to have this work-a-rounded it in >> gcc. But well, I won't die if it isn't. ;) > > You can use other environments (e.g. cygwin or interix) to build native > gcc under Windows, with a bit of tweaking.
I know about that. And in fact I am use Wine for doing an native compile. Nevertheless most users using msys for native windows. Btw that it would work on cygwin is more theory, as you need to replace here system's make ... but well, I admit, if I tweak enough, its possible. Interix is another nice approach, but for most people simply unavailable due you need more then a windows-standard edition to use it for free. >> Yes, understood. But some lines down in Makefile we use LN_S with same >> pathes, but with filenames on all two arguments. So I think this fear >> might be without reason here. (see section "Copy new target dependent >> sources"). > > The section you are referring to concerns a different and much smaller set > of files, so will not be affected by command line limitations, so this is not > comparable. Sorry, here I am a bit curious. Maybe I am just unaware, but what have the arguments of the LN_S call to do with the amount of entries in the list, which are getting enumerated by foreach? The $f variable anyway will contain just one filename, isn't it? Is such an foreach loop unrolled before execution so that I have 'elements-in-foreach' * 'size-of-executed-command'? Kai
