On 8/3/06, Junio C Hamano <junkio@xxxxxxx> wrote:
>> What's the standard workflow/procedure ActiveState users would >> use to build and install .xs extensions? Maybe they have their >> own $(MAKE) equivalent that groks such a Makefile with >> backslashed pathnames and CRLF endings? > > I don't know. It's a bit more than backslashes and CRLF. The pathnames > must be _completely_ converted from windows to cygwin. Cygwin even > provides an utility for that (cygpath). Besides, there still is that stupid > case-sensitivity problem. What I meant to say was that the real mistake might be for us to try using the Cygwin toolchain (GNU make, gcc and GNU C library) while working with ActiveState.
Luckily, only ActiveState Perl users are hit. Which, I suppose, is not all that much (it's really crappy environment to work in, an only real stupid corporate users can keep doing that), and they're used to pain.
Now, I admit I know very little about ActiveState and know nothing about Windows build environment, but I would not be surprised if in ActiveState land there were a MakeMaker equivalent that spits out Makefile equivalent that is suitable for MS development environment, and the users are expected to work in that environment, perhaps using MS C compiler toolchain,
AFAICS, it is not suitable for anything: generated Makefile is not parsable by nmake(what MS thinks is a make) and is more like a broken gmake Makefile. Also -fno-strict-aliasing points at gcc.
to produce object files if they want to link with ActiveState stuff. If that were the case, maybe what is needed is to port the build infrastructure to MS development environment, and making Makefile generated from perl/Makefile.PL usable might not be of much use.
I'd suggest to add NO_PERL_XS option to the top-level Makefile. Really core tools do not need Git.pm. - : send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html