c89 compatibility (fixed)

[surfskidude]

I had to make some minor changes to get it to compile on a c89 compiler. See attached file diff.txt .

I also had to change the name of bson.c since the same file name is in the Mongo C driver: mongoc.org

[neoxic]

Is it a real-life task to compile it on C89, or did you just do this out of curiosity? Because I doubt mongoc will compile on C89 itself. :-)

[neoxic]

I also had to change the name of bson.c since the same file name is in the Mongo C driver: mongoc.org

Wow... How on Earth is that a problem since libmongoc usually comes as a compiled library? Unless of course you manually put all the files of both codebases in one directory and compile them altogether...

[surfskidude]

Mongoc compiled without a hitch using VC++ 2010 and I have it all working. A library is just a collection of object files and yes it is a problem if two libs use the same object file name.

[neoxic]

Mongoc compiled without a hitch using VC++ 2010 and I have it all working.

I compile this project regularly using VS 2013 Express without problems. I'll look through your patch to see if I can apply some changes (not all of them are portable to other systems as for now). However, it's probably easier to just mention the dependency on VS 2013 Express for building on Windows.

A library is just a collection of object files and yes it is a problem if two libs use the same object file name.

Again, I compile on Windows regularly using both CMake and LuaRocks building methods with no problems. Could you post exact steps how to reproduce your problem?

[neoxic]

I applied your patch. Thanks for reporting! It's not quite a C89 compatibility issue per se because mongoc cannot be compiled in real C89 (aka ANSI C) mode. It seems VC++2010 lags behind in supporting some of the C99 extensions that I missed because VS 2013 is apparently more "advanced" and doesn't produce these errors.

As to the filename issue, please provide more info (commands and output) on how to reproduce it. Thanks!

[surfskidude]

I had both libs produce object files in the same output directory. This caused the problem. In any event, I recommend changing the name of bson.c to lbison.c. In fact, I recommend prefixing all files with l.

[neoxic]

Well, it is obviously not a good idea to compile any two or more libraries in the same directory. Prefixing is generally used for public C API to avoid conflicts, i.e. public header files, function names, types etc. should be prefixed. Internal source files, functions and types are not intended to be mixed with anything else, hence the building instructions that should be followed to build successfully.

If one follows the provided building instructions and gets errors, that's a concern.

[surfskidude]

No I am not following your build instructions since I am not using nor can I use LuaRocks. I am not building for standard Lua.

[surfskidude]

In case you are curious to what I am working on. The complete build script can be downloaded from: https://makoserver.net/download/MongoDB.zip The script downloads the code and builds a shared library for the Mako Server.

[neoxic]

Well, I glanced at what you are working on. I am no one to tell you my opinion, but in case you are interested, here it goes....

Subjectively, you are doing things the hardest/riskiest/buggiest way possible. I mean I can understand if you don't have a packet management system or want completely customize your builds. But instead of building your dependencies as static libraries and linking with them, you hack their sources, mix everything together and compile them as one common source base. That's insane!

Not only does it make your code solidified against specific hard-coded versions of your dependencies because you have to have your own file lists/projects/patches/other custom hacks for them instead of using their native building tools, it can also lead to very subtle bugs due to conflicting/forgotten compilation flags, conflicting filenames (as you have already seen), function declarations, compiler attributes, etc. which eventually makes the whole thing a ticking bomb ready to detonate. Leave alone the maintenance hell when you need to regularly update all the above each time a new version of your dependency is released.

I can also understand that you need some custom wrappers around Lua bindings to acquire mutexes or whatever. That's an unrelated design question. But instead of wrapping every module modifying their code, it would be much easier to patch Lua itself only once by redefining Lua macros lua_lock, lua_unlock, luai_threadyield, luai_userstate* before compiling to fully customize Lua state locking. Additionally, LuaJIT extends the Lua API by providing a way to call a wrapper C function via LUAJIT_MODE_WRAPCFUNC - http://luajit.org/ext_c_api.html

But what about mongoc? It has nothing to do with Lua at all. Why would you want to mess with it the way you do? Why not compile it statically and build lua-mongo against it, of course, providing some custom variables along the way like PKG_CONFIG_PATH? You could also drop the REQUIRED attribute for pkg_search_module()/pkg_check_modules() and provide LIBMONGOC_INCLUDE_DIRS/ LIBMONGOC_LIBRARIES variables from command line. Even if that is not enough, you could patch the provided CMakeLists.txt with your custom settings. That's the trick package maintainers resort to when there is not enough flexibility in the provided building tools.

If you really really want to go berserk and circumvent the building scripts/tools altogether by creating your own Makefiles for each library (exactly what you are trying to do), why would you want to mix all source together when it's much more flexible to compile each component separately as a static library and link everything together as the last stage?

My point is that there is absolutely no reason to do things the way you do. You could research more on static linking and configuration tools like make, autotools, cmake, etc. No need to suffer. There is a whole world of bliss beyond that. :-)

Hope this helps...

[neoxic]

As a side note, by combining substantial parts of source code from other libraries together without exposing their copyright notice, you may be in violation with their licensing terms if your project is public.

[surfskidude]

I appreciate that you take the time to provide your input, but I do not necessarily agree with you. What I have done is no more than test code and providing my own makefile was much faster than attempting to use the Mongo C driver build (especially for Windows).