On Sat, 12 Mar 2005 13:52:49 +0100, Quentin Mathé <[EMAIL PROTECTED]> wrote: > Le 11 mars 05, à 06:53, Yen-Ju Chen a écrit : > > > Great work !
Thanx. > > 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 also have issues about it, and I haven't figure out how to do it in a decent way. [snip] > *** > > For include : I plan to have a flat header directory. Right now, it is just for porting so that I can monitor the progress easily. Once I finish the porting and the headers are stable, I will put them into a flat directory. [snip] > > - 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. I do not understand what you mean here. :) > > 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/ Could you send a patch for this ? Now, I can only test with cocoa (don't have PC/Unix around). > > 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. I do have problems with link and haven't have time to solve it. I believe there is an easy solution but I just don't have time to play around it yet. :) > > 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. How do you put the test in the classes ? The classes are complied as library and the test are bundle. Do you have an example ? Do you mean puting the classes and test in the same directory or in the same file ? > > There is one test failing with GNUstep it seems ;-) : > TestDateTools.m: 20: warning: msgUKStringsEqual.fail It is about millisecond. Maybe there is a bug in GNUstep. It is not used by GNUstep though (there is no way to set millisecond). > > Let me know when you want to use Étoilé cvs for LuceneKit. Probably after I port every classes and put the copyright in. I want to make sure I can finish it before putting into CVS. And I would like to have a stable directory structure (ex. flat headers) before it goes into CVS. Have fun Yen-Ju > > Thanks :-), > Quentin. > > -- > Quentin Mathé > [EMAIL PROTECTED] > > _______________________________________________ > Etoile-dev mailing list > [email protected] > https://mail.gna.org/listinfo/etoile-dev >
