I can't make a Stand alone exe file in VFP9. I have tried the following codes.
BUILD PROJECT XX FROM MAIN
BUILD EXE MAINEXE FROM XX
It will make an executable file. But its not a Stand alone. Any solution?
You cannot make an executable with VFP that would run without any runtime files. All you need is to add those few DLLs (listed below) to your executable's folder (if you don't have any other dependencies like FLLs, activex):
Vfp9r.dll
Vfp9t.dll
Vfp9Renu.dll
Note: If you think about it, that is the case with many languages out there. There are not so many languages where you can build native all-in-one executables (C, Go as examples).
Related
I have been trying to install PDcurses on my Windows 10 machine. The README.md says to run: make -f Makefile to build pdcures.dll in the 'wincon' folder. However when i ran this in Powershell it did not create any .dll, instead creating many .o files.
Then i tried to run 'make -f Makefile.wcc' in Powershell and it returned the error 'makefile.wcc:9: *** missing separator. Stop.' I got similar errors using Makefile.bcc and Makefile.vc.
What am i doing wrong here? Am i supposed to build one of the .c files?
Each of the Makefiles is compiler-specific, as described in the README.md. There's no reason to try Makefiles intended for compilers other than the one you're using.
The Makefile doesn't build a DLL, by default -- only a static library (ending in .a or .lib). PDCurses is a small library, and there's not much benefit in building it as a DLL. But if you want to, that procedure is also described in the README.md. In short:
make DLL=Y
but please read the file for details. Note that, even if you build PDCurses as a DLL, you'll still also need the .a or .lib file to link against.
I have read through most of OpenMesh's documentation, and am lost in how to run a simple program using OpenMesh. I followed the tutorial for making a basic cube and building the project: http://www.openmesh.org/media/Documentations/OpenMesh-6.2-Documentation/a00068.html but nowhere do they mention how to RUN the program. The tutorial says to put the file that makes the cube in a particular folder: http://www.openmesh.org/media/Documentations/OpenMesh-6.2-Documentation/a00066.html and I did this. It clearly compiled the code when I built it with cmake and make. After that I am lost.
Assuming you used the CMakeLists.txt as given in the page you linked as-is, the linker should create a file MyOwnProject within the directory where you executed cmake and then make. That's your executable. To run your program, execute that file, either by double-clicking it within a file manager (Explorer, if you are on Windows) or by typing ./MyOwnProject on a Linux command line.
My question is very naive. Every time I ran an algorithm, it's with an IDE so I don't know exactly what is generated in backgrown.
I try to run with my MacBook an algorithm that I didn't write and I'm blocked !
In the readme file: they said "Use cmake to generate desired projects on different platforms. (See “CM.txt” in the
“src” folder)"
In the CM.txt:
project(BlProj)
cmake_minimum_required(VERSION 2.8 FATAL_ERROR)
add_executable(BlProj
main.cpp
thi.cpp
thu.cpp
mat.cpp
Config.cpp
Stringer.cpp
)
I did: cmake CM.txt
A CM directory is generated. I will not list all the files inside: it's some cmake, bin, out, cpp, c, cxx, log, txt files.
I don't know what I can do with that!
I'm supposed to generate a compiled binary and run it with the command:
./BlProj data1 data2 10 config output
But it wasn't generated...
So I don't know how I can have the BlProj executable. Could you help me?
How do the cpp compilation work? What did cmake exactly?
Is cmake CM.txt is a good practice or not?
You can use cmake-gui to build sources.
go to CMAKE installation directory and inside bin folder run cmake-gui
Provide input where the source code is and provide an input where to build.
hit on configure and then generate.
you might need to select IDE version as well as provide additional input, it depends.
once done open generated project files with your IDE and build.
I want to use Qt in my new project. An installer for my target compiler (VS2010 64bit), does not exist.
I am using Windows 7 64-bit with Qt 5.1.1.
A colleague of mine is also planning on using Qt and has managed to compile it for my target compiler (which he uses as well). He has built it in some directory, say DirA. He graciously gives me a copy of his entire Qt SDK build (binaries, examples, headers, and all), and I copy it to DirB on my machine.
I need it in DirB, because that is where all my 3rd party libraries are installed, and my CMake scripts know how to find them. I also added the Qt bin folder to my path.
Problems ensue. Qt binaries for some reason have the install path (in this case the build path) hard coded within them. So even though the Qt bin folder is in my path (so DLLs are found), Qt's DLL(s) are looking in the wrong place for the windows "plugin". They are looking in DirA, which does not exist on my machine.
So from what I found researching, using a qt.conf file specifying the install path root, is supposed to be the way to go. I add one to my Qt bin dir, and now Qt binaries (assistant, qmake, etc) can run.
But now I build one of the examples. Builds fine. Run the exe, Qt DLLs load, and then it crashes because it can't find plugin directory.
A work-around my colleague and I found that seems to work, is to copy my qt.conf file to the directory my exe resides in. After doing that the exe runs.
But this does not seem right. My exe can find the Qt DLLs, but the Qt DLLs it loads can't find qt.conf. They don't know to look in their own containing folder. I must have qt.conf in my working directory (my exe dir) for it to be found and used.
Does anyone know why this might be happening, and know of a way for me not to be forced to have a qt.conf file in my exe's dir? I can't accept this requires a rebuild of Qt. There must be some other way.
You can put qt.conf into your binary. Using the resource system.
From the Qt docs:
Without qt.conf, the Qt libraries will use the hard-coded paths to
look for plugins, translations, and so on. These paths may not exist
on the target system, or they may not be accesssible. Because of this,
you need qt.conf to make the Qt libraries look elsewhere.
QLibraryInfo will load qt.conf from one of the following locations:
:/qt/etc/qt.conf using the resource system
Or:
Using QApplication::addLibraryPath() or
QApplication::setLibraryPaths(). This approach is recommended if you
only have one executable that will use the plugin.
If you add a custom path using QApplication::addLibraryPath it could look like this:
qApp->addLibraryPath("C:/customPath/plugins");
I have a problem.
I am currently working on a linux application (let's call it BigApp in this scenario). This application needs to be customizable via shared objects(so) and ini/text files.
The prerequisites for creating such shared objects are:
Generating a C file in a custom location (done from code)
an additional h file from the source repository of BigApp (done via makefile)
an executable shell script in the application bin folder (done), which sets up some parameters, calls the internal c file generator described above at number 1, and calls some kind of build script described below.
"the" build script which should compile the h file and the generated C file into a shared object.
The problem I have here is that once BigApp is installed, step 3 (compiling a new shared object) should be done by anyone with some basic linux-like skills. Also, the build script at number 4 should somehow use the same settings which were used when compiling and installing BigApp.
BigApp uses automake (makefile.am, configure.ac files for root and subfolders).
I assume I need a Makefile.am template to generate a particular makefile for the shared object when running configure on the BigApp, but I have no idea how to do this while avoiding it being run when I "make" the BigApp.
I could use any kind of suggestions or references to a tutorial.
Thank you!
EDIT: at the time, the build script for the shared library/object is a small shell script which simply calls gcc two times, but with no particular platform settings, and no relation to the BigApp makefiles.
It's been a while since you posted this question but what you should do is turn your current makefile for your shared libraries into a Makefile.in (or even write a Makefile.am using Automake) that gets completed by your configure script (created using Autoconf) for BigApp. You should study the GNU Build system manuals.