On 07/02/2011, at 6:47 AM, Geert De Peuter wrote: > ".." has been portable on all OS's we compile on. That's any UNIX variant, > OS/2 (where are the days), OS400 and Windows (since it's earliest versions).
Are you sure? Because in Unix "." means "relative to this file", whereas on early MSC compilers it meant what it said: "relative to current directory". It follows by "logic" (if that applies to anything!) that ".." means "parent dir of current file" and "parent of current directory" respectively. With "make" these are often the same because you cd into the build directory. Felix build *disallows* changing the current directory or depending on it (except once at startup to determine the repository location, and that can be overridden). We mandate explicit paths for all input and output files. Eg you are not supposed to write: gcc -c x.c you have to put gcc -c x.c -o x.o > I agree having the JudyCommon in the library search path indeed doesn't > require this ".." reference. This is also a minimal change. > > The good thing about the approach we took is that we didn't change the > original distribution. We just wrote our own makefiles on top and added a > few files with "#include" directives. > Builds are simply not allowed to do a copy, that's a strict policy we follow. We don't do a copy in the build, the copy is already in the repository. > Reason is simple - the source directory may be shared (remotely mounted) on > multiple machines that will do platform specific compilations. You don't > want to have bizarre race conditions in a build system when multiple systems > use the same source and while one is reading the file - another system > decides to run a copy job. Actually, our system "supposedly" disallows building in the repository image, which is assumed to be read only. So we actually copy most of the source to a specific directory: build/release, build/debug, or whatever. That eliminates the above problem. It's all "supposed" to work without copying though, but not all tools can handle this. Our system is a cross-cross-compiler so the kinds of things we need to do are quite nasty :) Felix -> C++ -> binary -> execute So actually we "should be" managing multiple configuration data, eg you might build Windows 64 bit code on a Linux 32 bit machine. [I'm not sure all that still works, but it was designed to support Cygwin and also Windows MSVC 32->64, 32->32 and 64->64 bit compilers, which is a LOT of hassles! I don't run Windows any more so I can't test it] > Last I wanted to mention that the #define JUDY1 is optional ... we added it > because it makes it easy for the reader - and there is no problem doing that. > It would just end up being one more directive to add to the makefile if you > didn't like that approach. Actually we refuse to use "make". It's a junk tool and also not portable. We decided building was a sophisticated process that demanded a proper language, we chose Python, Erick wrote "fbuild" which is based on the idea that building is a sequence of imperative operations, it uses caching to avoid repeating something already done (i.e. it's an optimisation). But of course we can just ignore makefiles :) Anyhow, it seems we agree on basic build principles, and the main thing is that it builds. The one real problem issue here is our macro header: #ifndef JUDY_EXTERN #if defined(_WIN32) && !defined(FLX_STATIC_LINK) #ifdef BUILD_JUDY #define JUDY_EXTERN __declspec(dllexport) #else #define JUDY_EXTERN __declspec(dllimport) #endif #else #define JUDY_EXTERN #endif #endif Our system here is: All externals in the library have to be marked "JUDY_EXTERN". For example: FUNCTION int JUDY_EXTERN Judy1ByCount The macros above, which we normal put in a #include "judy_config.hpp" file, but not in the case of Judy, are required to decide what _declspec to emit: dllexport or dllimport. This requires a command line switch (there's no workaround for this), we use two: BUILD_JUDY: --> we're building the library rather than using it FLX_STATIC_LINK: -> we're making a static lib, rather than a DLL Together with _WIN32 switch from the compiler this decides whether to use dllimport, dllexport or nothing. There are some variations on this of course but there is no way to avoid modifying the code with JUDY_EXTERN or equivalent. To avoid hassles with shells, it is best MACROs specified on command line are "defined or not defined" rather than have a value, which means the JUDY_EXTERN macro has to be defined in the source code. We build all our C/C++ code with Python script that "always gets this right" for all libraries, but it only works because the protocol is fixed. Clearly Judy does not want to use "FLX_STATIC_LINK" macro. I'd be happy with anything which works of course :) -- 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
