Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

sqlite3pp as header-only library #16

Closed
jpetso opened this issue Sep 3, 2015 · 11 comments
Closed

sqlite3pp as header-only library #16

jpetso opened this issue Sep 3, 2015 · 11 comments

Comments

@jpetso
Copy link

jpetso commented Sep 3, 2015

The code is mostly forwarding to sqlite3 functions directly, and no build system is provided as sqlite3pp is meant to be included directly into the project tree (as far as I understand it). I think this makes it a perfect candidate for being a header-only library.

I would imagine it needs only a few changes:

  • Declare all exportable symbols (probably just class methods) as inline.
  • Rename .cpp files to .ipp and include them from the .h
  • Put all of that into a folder include/sqlite3pp, so parent projects can add [sqlite3pp-repo]/include to their include directories.
@jpetso
Copy link
Author

jpetso commented Sep 3, 2015

This would also reduce the need for something like PR #10 (although a similar CMake script to install the header files could make life easier for users not using git submodule).

@iwongu
Copy link
Owner

iwongu commented Sep 3, 2015

I'm not so sure about making this header-only. It has a benefit of easier installation but has some disadvantages too such as compilation time.
I still prefer having cpp files.

@jpetso
Copy link
Author

jpetso commented Sep 3, 2015

Given the (fairly minimal) amount of code in sqlite3pp compared to existing system headers, and the number of files that you're actually likely to use it in, I don't believe compilation time to be much of an issue. (Much bigger libraries such as Boost or websocketpp do header-only on a routine basis and while Boost is not loved everywhere, compilation times are the least of complaints I hear/read about it.)

Header-only also has the advantage that no symbol clashes can occur. As an example, if I build sqlite3pp as part of my libsomething.a and also include it in libsomethingelse.a, I can't link both of them together into a single executable without first factoring out sqlite3pp into a separate library (which was what issue #10 wanted to do but you were not in favour of it). With a header-only library, no symbols are exported so I can link both of my libraries together without any further work.

However, I understand that this is your project so you have final say over its direction. Thank you for considering it :)

@koziez
Copy link

koziez commented Dec 14, 2015

I would also love to see this feature

@rcmgleite
Copy link

+1

@iwongu
Copy link
Owner

iwongu commented Feb 9, 2016

fyi, I'm considering this change positively.

@sr1919
Copy link

sr1919 commented Feb 10, 2016

+1

@iwongu
Copy link
Owner

iwongu commented Feb 10, 2016

Can some of you test this branch if you are interested in header only version of sqlite3pp?
https://github.com/iwongu/sqlite3pp/tree/headeronly/headeronly_src

@iwongu
Copy link
Owner

iwongu commented Feb 10, 2016

I merged it to master branch. I'm closing this issue. Please report bugs if you find any in header only version.

@iwongu iwongu closed this as completed Feb 10, 2016
@jpetso
Copy link
Author

jpetso commented Feb 10, 2016

Thanks! :D
I'll try it out and report back if something turns out not to work.

@jpetso
Copy link
Author

jpetso commented Mar 23, 2016

Since you left a note on the README, I thought I'd comment to say that we're trying it and it seems to work here :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants