Le 11 mars 05, à 06:53, Yen-Ju Chen a écrit :
This is a newer release of Lucene port.
The name changes to LuceneKit, and it uses a Etoile-style directory.
CVS version (1.9) of Lucene is now the target since it dffers quite
a lot from 1.4.3.
Most of the org.apache.lucene.analysis is ported
though the most important one, org.apache.lucene.analysis.standard
is not yet
because it use JavaCC to generate source code.
The next release may take a while to work out.
Help is very welcome.
Have fun.
Great work !
I just tested compilation under GNUstep, it works well, however Tests
doesn't work because of headers and linking issues.
Possible solutions I would use below…
***
For link :
I needed to use XXX_LDFLAGS to link needed libraries with my other
tests bundles, XXX_OBJC_LIBS didn't work on my side.
***
For include :
A remark : I think it would be better to have all LuceneKit headers in
a flat LuceneKit directory without subfolders like Util, Analysis etc.
because #import <LuceneKit/Util/Whatever.h> looks strange in my
opinion. What do you think ?
I think you have two solutions to solve the technical problem :
- Use a GNUmakefile.postamble in the root directory to create temporary
LuceneKit directory which contains the whole headers set in order to
allow writing #import <LuceneKit/Whatever.h> in your tests
implementation files
GNUmakefile.postamble example within UnitKit :
before-all::
rm -rf ./Source/UnitKit
$(LN_S) ./Source/FrameworkSource ./Source/UnitKit
after-clean::
rm -rf ./Source/UnitKit
- Keep the directory structure dependent include, like #import
"LuceneKit/Util/PriorityQueue.h"
The first solution is better in my opinion because the tests bundle
would have the possibility to be used without LuceneKit source code.
To have the Tests bundle working with GNUstep on Mac OS X I wrote in
GNUmakefile :
Test_LDFLAGS = -lUnitKit -lLuceneKit
Test_LIB_DIRS = -L../Source/$(GNUSTEP_OBJ_DIR)
Test_INCLUDE_DIRS = -I../Headers/
Not sure but may be there are bugs in gnustep-make because
Test_OBJC_LIBS and Test_HEADERS_DIRS cannot be used, their values seems
to be ignored
There is still a problem however, out of the box the linker won't find
libLuceneKit, you need to adjust LD_LIBRARY_PATH (or DYLD_LIBRARY_PATH)
or rely on static linking, I think it's better to keep dynamic linking
to avoid recompile process when not needed.
The fact is… my previous GNUmakefile proposal will work only if you add
../Source/$(GNUSTEP_OBJ_DIR) value to your LD_LIBRARY_PATH (or
DYLD_LIBRARY_PATH). What I can do to improve this : may be parse
LD_LIBRARY_PATH (or DYLD_LIBRARY_PATH) when ukrun is started and
retrieves the right value by parsing GNUmakefile in tests folders,
finally when ukrun exits I would take the time to clean
LD_LIBRARY_PATH…
Any comments ? May be I have missed a more obvious and elegant solution.
Last point, in the future it would be probably better to move the unit
tests inside LuceneKit classes itself because UnitKit has been written
to be used in this way, and better reasons : it would made the tests
code simpler in some cases because you would be inside objects with
possibility to use self, super, direct instance variables read/write
etc., it would document the code in a basic way for contributors, it
would be more evident you need to adjust the test method code when you
edit the related implementation method, and it would avoid the linking
problem outlined above.
When I will have the time, I plan to add tests stripping for deployment
in order to avoid dead methods in runtime when UnitKit isn't linked.
There is one test failing with GNUstep it seems ;-) :
TestDateTools.m: 20: warning: msgUKStringsEqual.fail
Let me know when you want to use Étoilé cvs for LuceneKit.
Thanks :-),
Quentin.
--
Quentin Mathé
[EMAIL PROTECTED]
