As a python user, if I require a module pip install whatever, it magically handles dependencies and such. Python spoiled me! I'm NOT prepared for the world of C++!
It has taken me some considerable effort just to simplify this question, so bear with me:
Essentially if I create an open source package (and it involves QT, but I suppose it could involve anything) I would like to know of an OS-independent standard of some sort that at least simplifies the dependencies issue, so if another developer gets involved he can quickly get up and running with the source.
Using pip as an example, if there are cascading dependencies, all will be added, and the developer quickly assembles his rocketship with auto-delivered parts and goes to the moon.
I haven't found a similar solution with c++, that honors platforms, but then again I am very new to this language. This question itself might suggest great misunderstanding of the subject.
Can someone set me straight on this?
Related
I'm definitely a beginner with Conan, and I've only used it with very small projects where pretty much everything is under my control. Loved it! However, this simplicity also makes me kind of unable to appreciate the use and interest of conan profiles. Why can't CMake and Conan talk kindly to each other to pass things like compiler versions and C++ standards versions?
I imagine that the (really cool) project cmake-conan wrapper is dedicated to actually formalize the "talk kindly to each other" part I so boldly abstracted away: but even if I entirely trust it's utterly complex, I still feel there is something I'm really missing here?
As I'm trying to migrate to Conan 2.0, the need to precise host and build profiles confuses me even more (I was doing fine without them for my baby libraries, why is it vital I precise them now and what do they do?). I feel actually a bit scared of Conan 2.0 and a part of me wants to stay away from it so I can stick with cmake-conan wrapper.
Is it possible to explain with (very) simple words why what seems to complexify my (very small) project management is worth the effort? Thank you!
A company asked me to program a GIT wrapper for them.
The people there have absolute no versioning systems experience, but it will be incorporated in their daily routine eventually (through my program).
I'm planning on using VC++ to create a tiny windows applet that will help ppl in this process. Any thoughts on that?
What about a Deamon process checking if people want to commit/push their files?
For almost (but not all!) use cases, libgit2 is the easiest way to interact with Git repositories via code.
Git already has two layers: The plumbing (which you may be interested in) on top of which is built the primary porcelain which provides the user interface. If you want to implement something like git-commit but with slightly different semantics all of the underlying programs like git-write-tree and git-rev-parse are there for you to build on.
See also What does the term "porcelain" mean in Git?
There's already TortoiseGit, among other "friendly" interfaces. Don't re-invent the wheel, start by researching what's already available.
In order to easier the search for documentation hereafter the link to the official. It's about the plumbing and porcelain:
https://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Porcelain
I have fairly large C++ library with several sub-libraries that support it, and I need to turn the whole thing into a python extension. I'm using distutils because it needs to be cross-platform, but if there's a better tool I'm open to suggestions.
Is there a way to make distutils first compile the sub-libraries, and link them in when it creates an extension from the main library?
I do just this with a massive C++ library in our product. There are several tools out there that can help you automate the task of writing bindings: the most popular is SWIG, which has been around a while, is used in lots of projects, and generally works very well.
The biggest thing against SWIG (in my opinion) is that the C++ codebase of SWIG itself is really rather crufty to put it mildly. It was written before the STL and has it's own semi-dynamic type system which is just old and creaky now. This won't matter much unless you ever have to get stuck in and make some modifications to the core (I once tried to add doxygen -> docstring conversion) but if you ever do, good luck to you! People also say that SWIG generated code is not that efficient, which may be true but for me I've never found the SWIG calls themselves to be enough of a bottleneck to worry about it.
There are other tools you can use if SWIG doesn't float your boat: boost.python is also popular and could be a good option if you already use boost libraries in your C++ code. The downside is that it is heavy on compile times since it is pretty much all c++ template based.
Both these tools require you to do some work up-front in order to define what will be exposed and quite how it will be done. For SWIG you provide interface files which are like C++ headers but stripped down, and with some extra directives to tell SWIG how to translate complex types etc. Writing these interfaces can be tedious, so you may want to look at something like pygccxml to help you auto-generate them for you.
The author of that package actually wrote another extension which you might like: py++. This package does two things: it can autogenerate binding definitions that can then be fed to boost.python to generate python bindings: basically it is the full solution for most people. You might want to start there if you no particulrly special or difficult requirements to meet.
Some other questions that might prove useful as a reference:
Extending python - to swig or not to swig
SWIG vs CTypes
Extending Python with C/C++
You may also find this comparison of binding generation tools for Python handy. As Alex points out in the comments though, its rather old now but at least gives you some idea of the landscape...
In terms of how to drive the build, you may want to look at a more advanced built tool that distutils: if you want to stick with Python I would highly recommend Waf as a framework (others will tell you SCons is the way to go, but believe me it's slow as hell: I've been there and back already!)...it takes a little learning, but when you get your head around it is extremely powerful. And since it's pure Python it will integrate perfectly with any other Python code you have as part of your build process (say for example you use Py++ in the end)...
I've found only two FastCGI libraries for C++. There's the "official" one, and fastcgi++. How is either one better than the other? Do any others exist?
What you probably want is hidden in the contrib directory of Cgicc package.
fcgi-test.cpp is an example of how to use cgicc with FastCGI.
Path to the installed fcgi-test.cpp should be
/usr/share/doc/libcgicc-doc/examples/contrib/fcgi-test.cpp
As fastcgi++ is still listed as "Development Status: 4- Beta" so I would suggest going for the official one. It has been around for ages and has bindings for a whole host of languages. Licences between the 2 don't seem to make much difference. Put some measurements in your code and if performance is an issue then spend some time playing around with alternatives.
The official library is rather low-level, and as such, is only useful as an intermediate for a high-level CGI library such as cgicc.
Fastcgi++, on the other hand, allows for use of C++ idioms when dealing with FastCGI. Incompleteness in v1 motivated me to fork it into mosh-fcgi.
Pros:
My fork complies with every point of the standard (especially ROLE_FILTER)
everything's extensively templated, so it's easier to use arbitrary T for std::basic_strings.
Cons:
My modifications are in alpha mode.
In any case, download the latest zip from https://github.com/moshbear/mosh-fcgi.
See also the Cgicc library:
http://www.gnu.org/software/cgicc/
The library appears to be mature (currently at version 3.x). According to the documentation it can be used with FastCGI by passing a custom reader (reader_function_t) to the constructor of the Cgicc class.
There is a pretty library for creating FastCGI daemons: https://github.com/golubtsov/Fastcgi-Daemon
The C-version of FastCGI does very little, and developing in C++ isn't such a big problem as it hardly interferes with your own code. It's most likely just a loop and an environment variable.
So my advice would be just to stick with the official version.
Just be aware of one thing: it works by redefining printf! So if you use cout it won't work.
I'm currently working on a project were I had to wrap the C++ classes with Python to be able to script the program. So my specific experience also involved embedding the Python interpreter in our program.
The alternatives I tried were:
Boost.Python
I liked the cleaner API produced by Boost.Python, but the fact that it would have required that users install an additional dependency made us switch to SWIG.
SWIG
SWIG's main advantage for us was that it doesn't require end users to install it to use the final program.
What have you used to do this, and what has been your experience with it?
I've used both (for the same project): Boost is better integrated with the STL, and especially C++ exceptions. Also, its memory management mechanism (which tries to bridge C++ memory management and Python GC) is way more flexible than SWIG's. However, SWIG has much better documentation, no external dependencies, and if you get the library wrapped in SWIG for Python you're more than half-way there to getting a Java/Perl/Ruby wrapper as well.
I don't think there's a clear-cut choice: for smaller projects, I'd go with Boost.Python again, for larger long-lived projects, the extra investment in SWIG is worth it.
EDIT - the Robin project is sadly abandoned, and won't be much use today
I've used Robin with great success.
Great integration with C++ types, and creates a single .cpp file to compile and include in your shared object.
I suggest SIP. SIP is better than SWIG due to the following reasons:
For a given set of files, swig generates more duplicate (overhead) code than SIP. SIP manages to generate less duplicate (overhead) code by using a library file which can be statically or dynamically linked. In other words SIP has better scalability.
Execution time of SIP is much less than that of SWIG. Refer Python Wrapper Tools: A Performance Study. Unfortunately link appears broken. I have a personal copy which can be shared on request.
pyrex or cython are also good and easy ways for mixing the two worlds.
Wrapping C++ using these tools is a bit trickier then wrapping C but it can be done. Here is the wiki page about it.
A big plus for Boost::Python is that it allows for tab completion in the ipython shell: You import a C++ class, exposed by Boost directly, or you subclass it, and from then on, it really behaves like a pure Python class.
The downside: It takes so long to install and use Boost that all the Tab-completion time-saving won't ever amortize ;-(
So I prefer Swig: No bells and whistles, but works reliably after a short introductory example.