<snip> > PREFIX and dicts should always be an absolute path. When will > "WIN32_USE_EXECUTABLE_DIR" not be defined? > This is the same old problem. I'm more willing to put another macro into the code then change the way someone existing project works without their permission. I know you expect software to change and when the release notes clearly state what you are changing, you expect your user to adapt or not upgrade. I worked for a lot of years at a company that had strict rules about changing output. I've also wrenched when reading stories about companies that got a bad reputation by releasing new versions that made customers spend a lot of time and money adapting to the change. And sometimes to retain compatability with other systems, you can't pass up an upgrade, so customer somethimes get stuck.
<snip> > I find something like that acceptable. > > > What do you think? > > > > Also why isn't HOME_DIR dirs.h? > > Because dirs.h is a generated file. It can be moved there if necessary. > It's not necessary, I just wondered. By the way, I found the perl code that is suppose to generate the dirs.h, and I tried to figure out the configure file, but I'm stumped. I don't know why that file is not generated. Should it just be distributed in the win32 subdir? The question is, do we need more macros provide better keyword defaults while we preserve existing functionality. _______________________________________________ Aspell-devel mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/aspell-devel
