I have a project with a bunch of C++ and Python/Cython files. Until now I primary developed the C++ part and compiled it to a static library with qmake. Some few methods are exposed with boost::python, and executed from a .py file.
I now wanted to compile the whole thing into a standalone executable.
My question now: what is the best way to do this? I tried to switch to Cython, compile the python files and linking the library. But it seems there is no direct way with distutils/setup.py to compile an executable, only shared libraries.
Is there a way to easily compile both .cpp and .pyx files into an executable at once?
So that I can get rid of a lot of the boost::python wrapper stuff and get a neat mix of c++/python without having to import a shared library and pack the whole stuff with pyinstaller?
You should look into:
pyinstaller (or py2exe) for windows/linux
py2app for osx
Since python is your entry point, you will be able to bundle a stand-alone interpreter, environment, and resource location into an app/exe/binary. It will collect all your library modules into its self-contained site-packages
If you don't use any normal pure py files and only have cython files, then it is also possible to embed an interpreter into one of them as an entry point with an --embed flag to cython:
http://wiki.cython.org/EmbeddingCython
Note, this is a similar "freeze" approach to the previously mentioned packaging options, but doesn't go the extra length to build a self contained env
Related
I'm trying to write a program in C++ to write static arrays and matrices to .mat files so that I can load them into Matlab, and I'd also like to be able to read them. I've done a lot of reading and I'm aware that there's some framework I need to properly set up in XCode in order for things to work. I'm using Matlab R2015b and Xcode 7.3.
I'm modeling my code initially to be simple like what the author mentions in Reading data from matlab files into C but I can't locate my libraries. The folder /glnxa64/ does not exist on my machine. I know that my headers I want to include are in applications/MatlabR2015/extern/include for mat.h, matrix.h.
I have two problems: Under my project settings in XCode, what do I modify to make sure my project finds mat.h and matrix.h, is it under the "Precompiled Headers Cache Path" or elsewhere? Also, where do I find those library files and how do I link them in XCode, is it just under the Project Build Phase link binary with libraries?
Thanks for the help!
I found the solution to the second part of my question. The first part was just me messing with the project build settings instead of the target build settings.
The folder for the libraries that Matlab has depends on what operating system and version of Matlab you're on. Opening matlabR2015b.app by making the finder show package contents, then navigating to applications/MatlabR2015b.app/bin/maci64/ is where the library binaries are located on my machine. The name maci64 changes depending on the OS (since I'm on a mac 64-bit OS, I believe that's where my path name came from) and manually paging through the list of libraries found it, since using the file search doesn't really work inside a package.
My code still won't compile because it looks like I need to include all of the right codependent libraries, and I don't know which other ones I need (I only included libmex.dylib and libmat.dylib), but I found where the libraries are stored.
I'm trying to write my first game in c++, and I want it to dynamically load everything from files. This includes the enemies, and I was wondering if there was a way to dynamically include their code at runtime, instead of linking the on compile, so that the levels are easily interchangeable. Lua might be an option but I have no clue where to start, and dll seems to be Windows-only (and I wouldn't know where to start there anyway). Can anyone help with this?
tl;dr I want to link in code to my c++ game at runtime.
For the Lua approach you first need to choose the version first. Right now there is the major version 5.1 and 5.2. My previous work was using 5.1 and for my new project I decided to update to 5.2, however I found that my favorite script wrapping tool (SWIG) does not work with 5.2. Just something to decide at the beginning, because you do not want to get a version working and then have to change it.
Lua comes with makefile build environment. My first experience of trying to build on Windows was a bit of a nightmare, did not appear to just run out-of-the-box, so I opted to create my own Visual Studio project at the time, and just include all the .C files in the project. There are two files which need to selectively included/excluded depending on how you intend to compile: lua.c and luac.c. If you are planning to embed Lua in your app, then exclude both of these files; they both contain a main() function and are designed to build console apps. Include all the rest of the C files in your project.
You should be able to compile easy from this point.
When you include the headers of Lua, keep in mind that the functions are C functions so if you are including them from C++ you need to wrap the file inclusion inside of: extern "C" {} - example: C++ Lua 5.1 Issue
Wrapping your interfaces in another topic and there are lots of resources available. My favorite is SWIG but there are lots of options, including hand coding the conversion of your C/C++ -> LUA -> C/C++ code. Would recommend just focusing on getting the first part working first, get the interpreter embedded so that you can run a "hello, world!" script from Lua inside your app.
So going by your requirement of crossplatform use and dynamic linking, what you're probably looking for is an environment like QT which has QLibrary: https://stackoverflow.com/a/9675063/453673
But https://softwareengineering.stackexchange.com/questions/88685/why-arent-more-desktop-apps-written-with-qt
MingW is the open-source equivalent for Visual C++, so it can help you writing code for Windows (though if I had a choice, I'd directly use Visual C++). The way dll's are loaded in Windows is somewhat similar to the way they're loaded in Linux, so you'll be able to write code with #ifdef's to do conditional compilation. I've written one such program a couple of years back.
To load a shared library(always with .so as suffix) under Linux, you could use dlopen(), dlsym() and dlclose()
how do I correctly implement Lua in a C++ program? I downloaded the Lua source, put the .c files in my src folder and the .h files in my include folder, included lua.h in my program's source code (with extern "C"{} of course) and hit "Build".
That's how all the tutorials tell me to use Lua with a C++ project.
But now I get the error "multiple definition of main" and some Symbols in the Lua code that could not be resolved. I understand what the first error means (conflict because Lua has a main and my program also has one), but how can I solve it?
Or did I understand something completely wrong about implementing Lua in a C++ program?
Check to make sure you didn't include luac.c, lua.c, and the source for any other programs that are included with Lua in with your source code. Lua's source includes a few extra utilities (i.e., luac), and chances are you've just included them in the project and forgotten to remove them, thus resulting in having more than one main.
In short, those are separate programs that you don't add to your project. If you can, just build Lua normally, link to the library, and include the header files as normal.
So, on the point of you misunderstanding how to use Lua, you probably did to some degree. It is entirely possible to just copy Lua's source into your code, though probably not advisable. What you really want to do is pull up the extracted Lua source in a terminal and build it. Then (according to Lua's INSTALL document), you'll want to type make platform, where you'll replace platform with whichever platform you're currently using (i.e., I'd use macosx, you might use linux, refer to the INSTALL for which platforms are supported). After that, it's up to you if you want to install it or not, but you'll just do make install (or sudo make install) to get that done.
After that, either add the appropriate linker flags when compiling to link to Lua (e.g., -llua) or alter your project's settings in your editor of choice to do roughly the same thing. That said, you'll want to refer to the INSTALL document provided with Lua for complete instructions on this.
I'm embedding Lua in my projects other way around, preferred way, IMO: compiled Lua as a static library.
Just comment the two main() blocks in Lua.c an Luac.c, then hit build and run again.
I made this on Lua 5.3.
I have written and tested a library in C++. The code even works in my Android application if I add the source files directly. While I do have experience compiling static and dynamic libraries for common operating systems, I have zero experience compiling for a mobile system like this. I've done some research, and I'm still a bit lost as to exactly how to approach this. For example, I am unsure of whether to build a makefile for use with ndk-build or to just invoke one of the Android's compilers directly.
I did see this question, but it does not quite match my situation. I just want to run build and have it spit out libfoo.a (I'd like to produce libfoo.so as well, but libfoo.a is of greater interest to me right now.) The example in that question's winning answer implied that it would build the library as one step/module for building the final application. I tried doing it that way just to see, but I had no luck.
Can anyone please guide me in this endeavor?
CLARIFICATION -- I do not want to build the library and immediately pipe it into an application. I want a .a or .so file that I can link against in multiple future Android applications.
Create a dummy java file with empty code and make sure there is a android_main function in your C++ code. Build using ndk-build. the resulting apk will make your library an application.
See the samples from the android-ndk-r5/samples directory, see the sample native-bitmap to get some idea.
If I understand it correctly that a shared library is not acceptable and you want to be static (but why is that so important?), probably the easiest way to do so is to simply supply source code that can be added to a project.
Ultimately there is nothing special about the ndk build system other than it knowing the right commands to issue to build the necessary files for the assortment of curent android architectures. If you really want to do something different, you can log the operation of the android build system in creating a shared library, and then write your own Makefile that performs the analogous steps to create a static library. HOWEVER, you will have to update your Makefile any time the underlying assumptions or target collections change in a new android version.
So basically, I am attempting to write my own GUI wrapper in Python (Using GTK+, but I don't think that's relevant) for an API that is written in C++ and compiled by the user into a shared object file (in linux [*nix? I'm not quite sure how it works on macs]) or a dll (in windows) that you should be able to reference to use the API yourself. After quite a while of trying with Cython, I am able to write my own extensions, as long as it is only a single file, but I can't find anything online about using multiple files (as this obviously is, since any real project would be) to compile into a single .so that can be imported into a Python project. Would I need to manually go through and use Cython and create .pyx files for each .cpp file (there are a lot of them), compile those into cpp files and then edit then use the make file to compile those into the .so file, or is there a more automated way? (p.s. I tried compiling each one separately with Cython, but it didn't seem to like the "#include < path/file >" notation and so couldn't compile most of the files)
Other info: I have been able to interface with the library using ctypes, but that felt extremely hackish and un-pythonic, and I want to get some more experience with Cython anyways, since it seems like it could be an extremely useful asset to have.
You could do a file named "yourmodule.pyx", rename all the others files to pxi, and do:
include "other1.pxi"
include "other2.pxi"
Then you'll have only one file to cythonize and compile: yourmodule.pyx.