I'm trying to package the Mac version of an open source application that I didn't write (I'm not much of a coder). I'm using py2app 0.6.4. The application builds on my system properly, but I'm unsure of what to list for the includes in the setup.py file.
The dependencies include qt4, PyQt, matplotlib, cherrypy, and sip.
When I looked at this article on handling PyQt applications, I noticed the dependencies were not listed simply as PyQt but rather *PyQt4._qt* etc. How can I determine what to insert in the includes statement from the code of the application?
When py2app runs, it's going to look at each of your scripts, automatically grabbing any modules or packages imported by your scripts. In many cases, this will suffice and you won't need to list anything in the includes variable. Some packages have extra files such as data files that aren't used by the import statement, but must be present for the package to run correctly. Then you need to explicitly include it so py2app will grab it as well. Try to use your app; if you get an error that some module or file isn't found then worry about putting it in the includes variable.
Related
I've build a small elixir application that uses NIF functions to execute some c++ code.
The nifs are loaded via:
def load_nifs do
:erlang.load_nif('<relative_path_to_lib>/<lib_name>', 0)
:ok
end
and this works fine.
Now I want to integrate this app into another project. The problem now is that load_nif throws:
Failed to load NIF library: '<relative_path_to_lib>/<lib_name>.so: cannot open shared object file: No such file or directory''
although nothing has changed. I checked the deps folder and the shared library files are exactly where they are supposed to be, so the dependency seems to be loaded correctly. I also tried putting the .so files into the same folder as the module that calls load_nif (and omit <relative_path_to_lib>/) as well as providing an absolute path, all to no avail.
Any help is appreciated, Cheers.
Relevant info regarding my system:
OS: Ubuntu 22.04
Elixir version: Elixir 1.13.0 (compiled with Erlang/OTP 24)
Update:
The issue does not seem to be that files are located at the wrong place, as it finds the files during the first test run after compilation.
However, the error occurs when I repeat the run. It seems that the error message is wrong, since no files are deleted during the test.
If I repeat the function within one test multiple times there's no problem, so the issue is not created because the NIF function is executed multiple times, but because the test that contains the function is repeated multiple times.
Solution:
I still have no idea what causes this behavior but after putting the .so files into a priv directory and accessing them via
:erlang.load_nif(:code.priv_dir(:<app_name>), 0)
the tests pass.
I am using the Dart's package:resource/resource.dart to load a file, it works.
But when I use dart2native to compile, it shows me the Unsupported operation: Service isolate is not available. May I know how can I resolve it?
The line for me to use the resource:
await Resource('package:core/assets/dev/ca.crt').readAsBytes()
The resource package is not doing anything clever, it's just running dart:io code to load files and using Isolate.resolvePackageUri to figure out where the file is.
My guess it that the latter does not work when you compile to native. That makes a kind of sense - if you compile to native, you can move the executable somewhere else. It no longer has access to the source code. The resource package tries to load resources stored in package libraries, which is where the program source is also located, and a native application doesn't have that available.
I'm not sure if there is a way to make it work using the resource package.
I'd probably instead move the resource I need so it's distributed along with the executable, and then try to find the file relative to the executable path (if you can find that). Avoid using a package: URI, they generally won't work well with ahead-of-time compilation.
Effective dart says
"DON’T import libraries that are inside the src directory of another package."
reason being it breaks abstraction and could potentially break your app if the library was to change its underlying implementation.
They do not provide an alternative or a solution.
Im currently working on a dart package that my app depends on.
What would be the correct way to import the models or classes from it instead of importing it directly from package src folder?
As previously mentioned in the comments, you can define which classes you can expose from your package. You're correct that it's recommended to avoid exposing more API than intended - it's also mentioned in the docs. To do this, you can define the exposed classes:
export 'src/your_file.dart' show ExposedClass hide HiddenClass;
I was following a tutorial for object detection using opencv, I did it step by step but when I run it, I got this error -
The program can't start because opencv_244d.dll is missing from your computer.
Try reinstalling the program to fix this problem.
I don't know what is the problem because I can see this dll in opencv libraries, I have added the following to the input dependencies:
opencv_core244d.lib
opencv_imgproc244d.lib
opencv_highgui244d.lib
opencv_ml244d.lib
opencv_video244d.lib
opencv_features2d244d.lib
opencv_calib3d244d.lib
opencv_objdetect244d.lib
opencv_contrib244d.lib
opencv_legacy244d.lib
opencv_flann244d.lib
This is still not working, what can I do?
You can find the required dll files into the bin folder (that is next to lib folder where the .lib files are located), and you have two options:
1) copy the required dlls into the same folder with your application //this is a little better because it kind of prepares you for when you'll need to deploy your application on systems that don't have opencv installed (for then don't forget to build the release version of your application)
or
2) add to the Path in the Environment Variables your path to that bin folder (be carefull that the path in there are separated by ; )
I would advise you to build the OpenCV libraries from source so that you can have a custom installation specific for your system (this is always better since it gives you the option of using what you want/need and also the performance is better since the libs are custom-made for your system).
OpenCV does not contain a library file called "opencv_244d.dll".
Check all your dependencies and their names so you don't have any misspelled names. All the names are something like "opencv_name244d.dll" such as "opencv_photo244d.dll".
I'm very inexperienced with Linux and the terminal, but I'm trying to learn. I've also never included an external library before. Now I need to include the Boost.Asio library in a program being developed in Ubuntu with G++.
Could someone very kindly and very carefully explain how to go about this, from the beginning?
EDIT:
Expanding on the original question: if I need to send this code to someone else for them to run it on a completely separate machine but in the same environment, how do I take that into account? If this whole process involves literally placing library files into the same folder as the code, do I just send those library files along with the .cpp to this other person?
You have mentioned you are using Ubuntu, so the simplest way to use boost is to first install libboost-all-dev package (from synaptic), which will install everything for you including those that needed to be compiled. Then you just need to use g++ in the usual way.
Please note that whether the version is what you want, if not, you may want to install it yourself. On the other hand, boost is mostly header only library, so you only need to extract the files (right click in Ubuntu...) to a folder and link to it while compiling:
g++ hello_world.cpp -I boost_1_49_0/boost
where the last one specify the path for compiler to find the boost headers (please use absolute path).
If you want to send your program to others, dont copy only some boost files, it does not work because of the dependence. Ask them to install the same environment as you while is easy (just unzip a file...).
I don't know about your specific IDE, or about Boost.Asio specifically, but in general:
Whenever you need to link to a library, there is a file named similar to lib???.a, which you need. You need to pass the -l??? flag to g++ to link to the file.
(I'm not too familiar with the details myself, so there might be other file formats and whatnot too...)
Regarding the edit:
The "right" way would be to just have them download the library themselves, and just pass -l??? to their linker. Including Boost in your source code will make it huge, and for no good reason... it's not like you include the STL in your code, after all.
You don't include the library, but instead you declare a dependency on it. Eg. consider you use autoconf and automake then you would add AX_BOOST_BASE1 to require boost and AX_BOOST_ASIO to require the ASIO libraries. In your Makefile.am file(s) you use BOOST_CPPFLAGS and BOOST_LDFLAGS macros and rely on the ./configure to set them properly. Then whoever consumes your code will have to run the well know ./configure script which will analyze the environment for the location of boost and setup appropriate values in the build environment so that the make succeeds.
Well at least this is the theory. In practice there is a reason the whole thing is better known as autohell. Alternatives exists, like CMake or boost's own bjam. But the synopsis is always the same: you declare the dependency in your build configuration and the destination location that consumes you product has to satisfy the requirement (meaning it has to download/install the required version of boost, in your case). Otherwise you enter into the business of distributing binaries and this is frowned with problems due to richness of platforms/architectures/distributions your application is expected to be deployed in.
Obviously if you use a different build system, like ANT, then you should refer to that build system documentation on how to declare the requirement for boost.
1: ax_boost.m4 is not the only boost detecting m4 library, there are other out there, but is the one documented on the GNU autoconf list of macros