Re: Building with pdump litters /usr/local/bin

Martin> I believe this is also the reason why pdump should _not_ be the Martin> default dumper when 21.2 is released. SJT> In my private capacity, I disagree. But the Release Manager has no SJT> opinion. Martin> Of course, for platforms where pdump is broken or non-ported, pdump Martin> should happen automatically (it doesn't currently). SJT> The Release Manager asks you to fix this. On all platforms, for SJT> testing. SJT> If you don't, I will. It is unlikely that I will be able to do it in SJT> a way that is easy to reverse at release time for appropriate SJT> platforms, unfortunately. I am not very configure-able. Martin> Are there such platforms? Sure. Irix with CC='gcc Martin> -mabi=64', for example. APA> Don't forget the potentially most prominent platform SJT> Which is why I want testers using the pdumper by default. There SJT> probably are very few, and those obscure, general bugs left in the SJT> pdumper, but I want to be as sure as possible. Making the Windows SJT> platform rock-solid in this respect is worth the slight risk to Unix SJT> platforms. You don't need testers. I've got enough platforms here at ETL. I am aware of various portability (!) problems with pdump and have a patch in progress for fixing them. pdump is not as portable as it looks. For example, it is not 64-bit clean. Besides, I was referring to the code we ship, not the current state of CVS. What we ship should be whatever's best for the users.