On Thu, Apr 30, 1998 at 08:35:06AM +0200, Oscar Figueiredo wrote: That's *exactly* the reason why I want one and only one option being chosen. I did not know about this problem, even if I have the resources (i.e. solaris 2.5.1 and the Sun compiler) to solve it. People just compile without minimal tagbits and forget it. The opposite goes for, say, cygwin and the lack of valid DATA_SEG_BITS definition. There is the same kind of problem with union type and alpha. Union type is required on alpha. Nobody knows why, mostly because everybody forgot about it and every people compiling on alpha is adding --use-union-type without thinking about it. Now that I know about it, I'm going to track it (there is something inflooping in the gc code). This may or may not unravel other problems. Such habits are understandable, but bad when we're approaching a release. I wouldn't like to see "Use minimal tagbits on cygwin", "don't use them on solaris with sun's cc" and "use union type on alpha" becoming answers to FAQs in comp.emacs.xemacs. But it is very easy to miss them if the failure report happens to come in at the wrong time. So please people, if you have some experience of "if I don't do this and that it does not work on my system" and the information is not yet in the PROBLEMS file, say so. Loudly. Every other snapshot. Or it will come back and bite us for the release. And please Steve, at least when code freeze is enforced, settle for a common set of options and enforce them in configure.in. I, for instance, have access to 7 different systems[1], 13 compilers total. I won't try 16[2] different options combinations on each. OG. [1] More if you count e.g. Irix 6.2, 6.4 and 6.5 as different. [2] mule, indexed lrecord, minimal tagbits, union type. I may have missed something. Double the number for each option.

Common combinations of options should simply work on all platforms. I've done a lot of work to make sure that union-type+mule works on Solaris, for example. Each such porting exercise cleans up the code base and makes XEmacs more portable. If we have a known combination of options that fail on some platform, it is very likely that it is either a basic cross-platform bug in XEmacs that needs to be fixed, or some platform-specific thing that can be tweaked in a few lines of code. Although we can't test every combination of options, some combinations are guaranteed to work everywhere: - configure - configure --with-mule The only excuse for things to be put into PROBLEMS is a vendor-supplied bug (such as HP's sed), not an XEmacs-supplied one. Although --gung-ho will not be the default (except perhaps for some platforms), it will be useful as a bug exposer. Developers demand more core dumps! OG> On Thu, Apr 30, 1998 at 08:35:06AM +0200, Oscar Figueiredo wrote: OG> That's *exactly* the reason why I want one and only one option being OG> chosen. I did not know about this problem, even if I have the OG> resources (i.e. solaris 2.5.1 and the Sun compiler) to solve OG> it. People just compile without minimal tagbits and forget it. The OG> opposite goes for, say, cygwin and the lack of valid DATA_SEG_BITS OG> definition. OG> There is the same kind of problem with union type and alpha. Union OG> type is required on alpha. Nobody knows why, mostly because everybody OG> forgot about it and every people compiling on alpha is adding OG> --use-union-type without thinking about it. Now that I know about it, OG> I'm going to track it (there is something inflooping in the gc code). OG> This may or may not unravel other problems. OG> Such habits are understandable, but bad when we're approaching a OG> release. I wouldn't like to see "Use minimal tagbits on cygwin", OG> "don't use them on solaris with sun's cc" and "use union type on OG> alpha" becoming answers to FAQs in comp.emacs.xemacs. But it is very OG> easy to miss them if the failure report happens to come in at the OG> wrong time. Right. Let's fix them. OG> So please people, if you have some experience of "if I don't do this OG> and that it does not work on my system" and the information is not yet OG> in the PROBLEMS file, say so. Loudly. Every other snapshot. Or it will OG> come back and bite us for the release. NOW is the time to make sure that all combinations of options work. OG> And please Steve, at least when code freeze is enforced, settle for a OG> common set of options and enforce them in configure.in. I, for OG> instance, have access to 7 different systems[1], 13 compilers total. I OG> won't try 16[2] different options combinations on each. Martin