On 06/02/2011, at 9:55 PM, Geert De Peuter wrote: > One easy change we did to make the Windows build system better was to avoid > the copies. > And it is totally portable to UNIX or other platforms as well. > > For example instead of doing the following in the build > cp JudyCommon/JudyFirst.c Judy1/Judy1First.c > AND > cp JudyCommon/JudyFirst.c JudyL/JudyLFirst.c > > We created a file > Judy1/Judy1First.c > Which contained > > #define JUDY1 > #include "../JudyCommon/JudyFirst.c" > > The file JudtL/JudyLFirst.c > would contain > #define JUDYL > #include "../JudyCommon/JudyFirst.c" > > The first #define (JUDY1 and JUDYL) is actually optional, but makes it easier > for people to understand the flow of things. > > This definitely avoids duplicate code (which is what Felix seems to have) and > strange copies of source code done by the build system
Yes, we have similar thing but the code is duplicated, which is bad. But there's a reason .. :) I do not believe ".." is portable. Sibling references are bad. It used to be in the old days Microsoft treated "." as "current directory" which means you could not use that either. Not sure what they do now. The proper solution is to put JudyCommon on the command line as a search directory: -IJudyCommon etc. This avoids the problem with using ".." in filenames. Actually in Felix C/C++ libs I "ban" subdirectories. You're not allowed to #include "a/b". All #includes must be simple names in double quotes (except system headers). This means all files must be searched for under control of the command line. I actually spent a lot of time with several big libraries modifying all the filenames. [Someone decided it was cool to have a file called string.h and refused to change it] Anyhow, that's why the code is duplicated in the first instance. In the second instance, the code is actually different, and the style of using threaded code like this is bad: this is a C level hack. Better to have two distinct files without the macro, even if that means maintaining each lib separately because that's probably easier than getting the macros right. Also the macros are global, and pollute space: you say #define JUDYL immediately before a #include, but what if you have two #includes .. one macro would modify both files, perhaps accidentally. The best solution is probably to use C++ templates :) YMMV: but what we have here is several people modifying the original code, hence my comment: the build system is disgusting. I repeat though: Judy itself is very cool and the C interface, though hard to use, is exactly right. It's hard to use because C doesn't have a strong enough type system. The Word_t typedef is probably the best compromise. With a few developers we could reorganise the repository and the docs, and let Doug get on with the R&D. I also need a way to iterate JudyHS, its useless as it is because there's no way to get all the values, which will usually be pointers, so you can delete them (in C) or in my case, not delete them (using GC, I need to mark all reachable pointers). I also wonder: why does Judy only allow a single word value (for JudyL+SL+HS). Is that fundamental to the design? Or is it just too hard to do anything else in C? -- john skaller [email protected] ------------------------------------------------------------------------------ The modern datacenter depends on network connectivity to access resources and provide services. The best practices for maximizing a physical server's connectivity to a physical network are well understood - see how these rules translate into the virtual world? http://p.sf.net/sfu/oracle-sfdevnlfb _______________________________________________ Judy-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/judy-devel
