You are likely to mess up the whole configuration.

Actually, on the first use of CPAN as provided by ActiveState, it asks you if you would like to install the whole compiler environment (you don't even have to install MinGW yourself) and it just works.

I even dare to suggest you re-install ActiveState Perl on your home computer, so you are sure that everything is up-to-date and working.

Well, everything was working before at some point, and got screwed up somehow. So, I think re-installing everything is a last resort, and possibly temporary solution, until it gets screwed up again. It's also mean re-installing a lot of modules again. And I'll learn nothing from this.

I don't want to copy as in copy files. I want to copy some settings, in particular compiler, linker, and makefile related settings. Making prior backups would be a key in this process.

Well ... sounds familiar.

I have been using AS Perl for many years, but for some unknown reason, the cpan of Perl 5.10 stopped working reliably.

Re-installing Perl cured it for a while, after which again it "broke".

I switched to strawberry-perl and had no problems since.

CountZero

A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity." - The Tao of Programming, 4.1 - Geoffrey James

In general, you should use the Active State ppm tool and their repository to install modules. You get something that was compiled with the "right" compiler for all the XS parts and it is a faster installation process.

The ActiveState modules use VC6 or mingw. The difference is that these link with the standard Windows memory management MSVCRT.dll, not some other one. This detail is important. This is memory management, malloc, free, etc.

If something does not exist in the ppm repository, I have found that the most often case is that some pre-requisite doesn't work on Windows and won't compile.

The number of modules that you install via the cpan shell versus the ppm shell should be very, very few (if any). Expect trouble every time you do this...Expect big trouble. If it is easy, ActiveState has already done it.

I am working on one: WWW::Mechanize::Shell and can't get it to work because of a non-compilable module on Windows. I don't know if I will ever get it to work. If by the way anybody knows how to get this done, please tell me!

If you want to re-install ActiveState...there are 2 important features of command line ppm that you need to know about:

ppm profile save    [ *filename* ]
ppm profile restore [ *filename* ]
[download]

Profile save will generate an XML file that describes all of your installed modules.

Uninstall ActiveState to the extent that you can. Run uninstall and if your installation is really old, you may need to delete some directories also. Then, New install of the base ActiveState PERL system, then run from the command line, the ppm restore command. This XML profile is transferable between machines. There can be complications with paths, etc. For example I have cygwin on my machine and ActiveState wants a different version of compiler and "make". Running the "restore profile" will set things in order.

If you have one machine on the same OS that works and another that does not. Then save the profile on the one that works. Do a un-install, then re-install, run profile file on the one that doesn't work. Of course I would keep a backup if this didn't work! I would imagine that you will have to do some manual installation the few modules on CPAN that are not in the PPM repository. There were troubles installing these to begin with and you will have to go through that again. If there were no troubles, then probably you would save yourself a LOT of grief by first looking at the ppm repository.

running the cpan shell on ActiveState is a desperation move. It should however talk you through the compiler and dmake installation.

An ActiveState install from the ppm repository is going to work. And has had at least some minimal testing by ActiveState. When you try to install a random CPAN module, it may or may not work under Windows due to a very long list of issues.

When you run the "cpan" for the first time, it will prompt for lots of stuff. This is similar in Linux. In general that program is smarter than you are about what you do and you should accept the defaults.

What did you do to break it? The lesson should be 'don't do that!', and then reinstall to fix it right.

A before & after diff of the install directory may help to figure out what broke.

It has always been my impression that the ActiveState team is more-or-less trying to deploy a system that requires no CPAN “intervention,” whereas the Strawberry team assumes that you do know about the cpan command and that you are quite likely and willing to use it.   It just might be that you are straying outside of the ActiveState designers’ intended scope.   (But of course, I do not know the members of either group, nor do I intend to speak for them...)

Both of these strategies, I think, make perfect sense... and they are intrinsically different.   Each team seems to have made “sensible, but sensibly different,” choices, and your choices might now be running counter to ActiveState’s, IMHO.   If you want to do what you seem to be wanting to do, you might find Strawberry to be more conducive and forgiving, whereas you might actually break ActiveState.   (Every good strategy has its price.)

all that may be, but something "brake" (changed) my config automatically, I assume it happened during some module install via cpan. what i find strange is that i can't find anyone who knows how to change config manually, neither here, nor on irc

what i find even more weird, and even annoying, is that here is a challenge, and all i can get out of people is "reinstall" or switch to another tool (which in this case the same thing). i know i can do that. but you know what guys, my AS Perl install at work works great, and has been for maybe as long as this broken one. there's no guarantee strawberry will work any better, and there's no need for strawberry specifically. i'm not switching. not until i learn what wrong now, anyways

If you want to mess with the compiler options (i.e. what you'd get with perl -V:ccflags), you can edit the respective entry in Config.pm, or more specifically Config_heavy.pl.

Run the following command to find out where those files are located:

perl -MConfig -E "say $Config{ccflags}; say for sort values %INC"
[download]

(I'm not convinced this will get you anywhere, but as you asked...   And don't forget to make a backup copy first.)

It has been a while since I used ActivePerl, but I recall last year they made the mistake of modifying ExtUtils::MakeMaker/Config to run ActivePerl::DocTools and override some config values. Its not the first time. Bug #45432 for ExtUtils-MakeMaker: EU::Liblist::Kid breaks ActivePerl + MinGW + PAR-Packer

I would try searching for bug reports on http://bugs.activestate.com/

You *can* change the compiler, linker etc that the toolchain uses, but you almost certainly don't want to, because most changes there will lead to you compiling libraries that aren't compatible with your perl. However, if you do want to, you need to then I think you need to fiddle around in Config.pm.

I presume that the machine that doesn't work has a perl that was built using a compiler that you don't have. The solution is to either acquire that compiler, or to acquire a different compiler and use it to build your own perl. You will then be able to compile XS-ish modules.