Skip to main content.
home | support | download

Back to List Archive

Re: Does the <!-- Swishcommand noindex --> work whe

From: David L Norris <dave(at)>
Date: Mon Jun 30 2003 - 11:37:43 GMT
On Mon, 2003-06-30 at 05:21, Frances Coakley wrote:
> I do test on Windoze but obviously that doesnt necessarily test other 
> distbs (eg my no-include prob under Windoze didnt seem to appear elsewhere)

Yes, exactly.  Problem appeared on Windows but not elsewhere.  :-)  And,
SWISH-E should be better tested across a wide spectrum of Unix systems.

A Windows-only problem is not at all surprising; especially with SWISH-E
2.2.x.  There are various obscure options to enable during the build and
I never knew if the Windows builds had all the right ones enabled. 
Before SWISH-E 2.3 the Windows builds were made with MSVC.  So, I had to
maintain my own build system on Windows.  That was alright until someone
changed anything.  So, the first thing I did with 2.3 was to patch up
the autoconf-based build system so it worked correctly for Windows. 
(And, that early 2.3 build system has since been replaced with a
libtool-based build system that seems to work much better.)

Another effort I made was to remove all Windows-specific code from
SWISH-E.  There were "ifdef _WIN32" conditions strewn throughout the
code before 2.3.  Very very few bits of Windows specific code remain. 
In fact, the only Windows-specific function I see right now is
make_windows_path() which is primarily to work around glitches in
Microsoft's stat() function.  It flips the '/' to '\' in filenames and
strips trailing slashes...  There's also a chunk of Windows code in
get_execdir() to find the helper scripts (libexecdir) at runtime whereas
on Unix that's set at compile time (e.g. /usr/lib/swish-e or

Now, in theory, Unix and Windows builds should work exactly the same. 
Barring any compiler or architecture differences, that is.  Where Unix
and Windows diverge is when running helpers during indexing.  Windows'
shell just isn't designed to work like Bourne and that causes some

> one problem in prop file name  - the x.y.z format is not allowed as well - 

That should be avoidable as long as you don't need an extension on your
index file name.  On a CD the index files could be named index and or similar.

> an additional flag (eg -fx ?) would suffice to specify prop file for me

That's perhaps not a trivial change.  Although, maybe not a bad idea for
the future.

Also, it seems like an increasing number of people want to put SWISH-E
index files on CDs.  So, it's maybe not a bad idea to support that by
default with minimal effort.

> in your compile script what processor do you build it for ? as C3 is not 686 compatible - 
> missing cmov instn - a build for 386, 486 or I think 586 is ok

The compiler is capable of 586 (GCC 3.2 i586-mingw32msvc) but I think
I'm using only 386 instructions.

I've not made any effort to optimize for a given CPU.  I experimented
with that once a few years ago and found that it could sometimes save a
few seconds on a run of a few hundred thousand files...  I also
experimented with Intel's gcc-compatible compiler which produced
executables that took a few seconds longer to run (than GCC executables)
on my Athlon system.  So, I settled on non-optimized builds as being a
good compromise.

 David Norris
  ICQ - 412039
Received on Mon Jun 30 11:37:49 2003