Christian Auby wrote: >Sure, this would be great as we wouldn't have to keep modifying our local >version to be able to use SOCI with boost.build.
Yes, this will definitely be welcome! >There are a couple of ways you could go to integrate it in boost.build: > >1. One jamfile at the root of SOCI with targets for the main soci lib and one >for each backend This is the approach I went with too. >2. One jamfile at root and one in each folder for each backend This seems kinda more work. >In either case you can set up aliases in the root which adds both main lib and >backend (since both are required). Yep. >We currently use 1 as it's a bit easier to maintain and you only have to add a >single file to SOCI to add boost.build integration. Agree. >We currently use a SOCI checkout from February 10th 2010. The only local >changes > >are: > >1. The addition of the jamfile, as per http://pastebin.ca/2024473 I attach my jamroot for soci here in the hope it might be useful. It uses a bit more elaborate approach, and _theoretically_ should be enough to support all the backends (I underline theorically because I haven't tested them all). Currently it assumes (on line 23) that the client libraries are in directories sibling to soci, i.e. they reside in the same parent directory as soci does. It is not an inherent limitation, just was OK for me that way, and in the official Boost.Build support the client libraries can be referred to in the same way as Christian does for sqlite3: /$(name)//$(name) or something like that. >2. Renamed sqlite3/blob.cpp to blob_sqlite3.cpp , same for sqlite3/session.cpp >and sqlite3/statement.cpp as these create object naming collisions in visual >studio (can't have two source files with the same name, even if they are in >different directories) Even though I vaguely remember something like that, I can't seem to find now if I had to make any modifications to circumvent such an issue. As a matter of fact, my jamroot for soci works OK for me with sqlite3 backend and msvc toolset, without having to rename or modify any of soci's files. >3. Changed const char nextChar = query_[pos + placeholder.size()]; > to > const char nextChar = query_.c_str()[pos + placeholder.size()]; > In statement.cpp as the previous would throw a debug assertion if a >placeholder was put at the end of a query string > >I'm not sure how many of the local changes we made are still required (how >much >has changed since february?) but I am willing to investigate this if it is of >use to you. IMO it would be in SOCI's best interest to work out of the box on >as > >many compilers and platforms as possible. > >Note that the jamfile above only supports the sqlite backend as that's what we >use. I can add the rest during Christmas break if you are interested. Same >goes >for testing on the various compilers we use if SOCI is heading towards a 3.1.0 >release. My Boost.Build support for SOCI has been tested under FreeBSD and Windows with sqlite3 backend. I think it has been tested with ODBC backend as well (under Windows), but I don't remember that very well so I'm not quite sure about ODBC. The jamroot has to be placed at SOCI root directory (just like Christian's jamfile). BTW, Christian, is that really a jamfile and not a jamroot? I can see a few issues if it is the former. Best Regards, Gevorg
jamroot
Description: Binary data
------------------------------------------------------------------------------ Lotusphere 2011 Register now for Lotusphere 2011 and learn how to connect the dots, take your collaborative environment to the next level, and enter the era of Social Business. http://p.sf.net/sfu/lotusphere-d2d
_______________________________________________ Soci-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/soci-users
