How to compile and run a C++ open source program? [closed] - c++

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 2 years ago.
Improve this question
This question may seem stupid, but as a beginner I did encounter this question when I moved forward, and I couldn’t find any information.
https://upload.cc/i1/2020/12/30/rUEC9s.png
https://upload.cc/i1/2020/12/30/d7Gwbr.png
https://upload.cc/i1/2020/12/30/6vr3lQ.png
This is an open source C++ program, I tried to compile and run it, but it failed
I have the following confusion:
Why the program does not have main.cpp
Update: When asking the first question, I even forgot helloworld.cpp, sorry
How do I compile and run it with CLion
Update: Usually I create a new project. After I create the project, it seems that it can be compiled and run for granted, but I don’t know how to compile and run an existing project (from others).
What do the folders in the first picture usually refer to
What does cmake and CMakeList.txt mean?
This open source program calls opencv, fftw and other libraries. I downloaded the corresponding files on the official website. How should the program call these libraries next?
If I download the library package on the official website, how should I install or configure it; if I install the package using homebrew, does that mean I have already configured it? Or I just finished downloading
I have written some programs in c++ and qt, but I don’t seem to know anything about c++
Finally, there is really nothing in the readme of this project

Your questions are too broad. Generally speaking, the answers would be something like this:
Naming your main file main.cpp is a convention, but is not required. What is required is a main() function (More info here).
You have to configure CLion to open Makefiles. There is a tutorial in CLion's website (Here).
What documents do you refer to?
src: Naming convention to the folder where the source (.cpp) files go.
include: Naming convention where the header (.hpp) files go.
License.txt: Where the software's license is written.
readme.md: Document that gives information about the project.
tests: Files to test the software.
cmake is a tool designed to build and package software (Their website is here). CMakeLists.txt is the file CMake uses to know how to create a Makefile and build the program.
You have to make the system know where the libraries are. You can achieve this by adding them to the project's folder or by adding them to the PATH of your compiler.
If you don't know very much about of C++ you should probably search a good C++ textbook. However, remember that Makefiles and C++ are 2 completely different things.

Most open source programs have build instructions somewhere in the readme.
It is usually best to follow those, even if they require downloading unfamiliar tools.
If the project doesn't have (detailed) build instructions, you should ask the owner, to add (more detailed) build instructions(by for example creating an issue for git-based repositories).

Related

Sending your c++ project [closed]

Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 2 years ago.
Improve this question
I have coded an app in c++ using the SFML library. I configured it into code blocks to run the program. Let's say I now want to send this app to my friend, what's the best way I can do this so that he doesn't have to go through downloading a lot of stuff to run it?
I am using the MinGW compiler.
Create an installer or package. For example; On RedHat Linux you'd want to create a RPM package. On Windows you want to create a MSI file. Whatever you do, the package you create should bundle up everything your application needs to run and put it into the correct location(s) on the target system. This includes your executable but also any libraries you use (including your compilers runtime libraries).
In most cases just shipping your .exe and all of its dependancies is enough.
In some cases you may also need to ship other files needed to run the application like configuration files, images, icons...
You can use copypedeps with the -r flag from https://github.com/brechtsanders/pedeps to copy your .exe along with its dependancy .dll files into an empty folder.
Then you can just zip everything in that folder and send it to somebody who can just unzip it an run the .exe.
Or you can make a proper installer to distribute the same files.
Your program needs some .dlls to run: some are the system ones, some are shipped with the compiler, and some come from the libraries you use (SFML). You need to ship all those .dlls (except the system ones) with your .exe, and they should be in the same directory.
It doesn't really matter if you make a proper installer or send your friend a zip archive. (If it's an archive, they might have to manually extract it before running the .exe.)
The question is how to figure out which .dlls to ship. There are several approaches:
Open the console, cd to where your .exe is, do set PATH= and try running the executable by typing its name. Since the compiler installation is no longer in the PATH, it shouldn't see the .dlls in there, and it should complain about them being missing. After you provide one .dll, it will ask for the next one.
A more civilized approach is to use a tool like ntdll to list all .dlls your app uses. Then copy them, ignoring the system ones (located in C:\Windows or subdirectories).
Note that both approaches rely on there being no extraneous .dlls in C:\Windows or subdirectories; some poorly written installers like to put their own .dlls in there. To check for that, make a list of all .dlls that come with your compiler (they should be in the same directory as the gcc.exe), and the ones that come from your libraries (SFML). Then look for the .dlls with the same name in C:\Windows and subdirectories, and if you find any, remove them.

Organizing the files of a project for multiplatform and easy-to-use [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 4 years ago.
Improve this question
Several years ago I created a C++ project. I used to write the code using nano and I compiled and linked it using a Makefile.
I simply had all the files into a single directory (including .cpp, .h and the Makefile itself).
For instance, I had a single inc.h file which was included in every single .cpp file, for example, something I now acknowledge as not very clean.
I would like to upload it to Github to make it accessible for anyone that wants to use it, with the problem being I can't seem to find any guide on how should I arrange the files (As there is, e.g., for creating packages in R). I have tried using Code::Blocks but I haven't managed to make the project work, so,
Can anyone point me to a guide that explains how to properly organize the code and data for C++ projects?
C++ itself doesn't have any style guide as to how to organize project files. It's one of the many little things that make package managers so difficult to realize. Every developer chooses their own organization, so if it works for you, just keep it in one folder. If you want to experiment with, e.g., separate header and cpp folders, there are examples around the internet, to be found when searching something similar to "makefile headers and source in separate directory".
For makefiles, you'd probably have to include something like
# preprocessor flags
CPPFLAGS := -I[path-to-headers]
in the line calling the compiler makefile
Most of the rules for C++ projects are project-specific, probably it's the main reason why there's no definitive guide. A couple of most generic recommendations I can think of (can be not relevant in your case):
Will your users need to include your header files? In this case put such headers into a separate "include" folder. Rationale: to avoid mistakes of including wrong header (one that is not part of your API), and to simplify analysis of your public API. I don't understand the rule to put all headers separately from .cpp files (e.g. default filter of VisualStudio projects), some headers can be for internal usage only.
Build to different folders (e.g. "bin" for shared libraries and executables or "lib" for static libraries) for each supported architecture and configuration. e.g.:
bin
|-- debug
|--|-- x32
|--|-- x64
|-- release
|--|-- x32
|--|-- x64
...
Rationale: simplify distribution and usage from external code.
you asked "how to properly organize the code and data". If you allow to provide some external configuration, or just general data, make sure you allow to specify its location instead of just hardcoding it. It's fine to hardcode the default location though. Ideally your API allows to specify the location in runtime if this makes sense in your case, or compile time option e.g. as an argument to your build script. Rationale: it will be much easier to test on different datasets/configs.

How to check the dll files required by my c++ file [closed]

Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 5 years ago.
Improve this question
I use Visual Studio 2017 Community for C++ coding. I have made a simple win32 console app and do not want to expose my code. I have also found the .exe file in the debug folder of the solution. When I try copying the .exe file in the Debug folder in another folder it says that the dll isn't found.I also tried copying the whole folder but the same error occurs. Please help me...I want to run my app on another computer also.
You can Generate Code Map for Solution.
Navigate to Architecture –> “Generate Code Map for Solution”
Generates a code map like:
Which shows the inter-dependency between modules and libraries.
In your case by just copying the exe, you are breaking the references to all of the required libraries. Depending on your scenario, you have two good options. Copy the entire source tree + dependencies for you project and recompile it in the new working directory or create an installer which will allow you to distribute dlls and any other required resources.
This is more complicated that one might hope. To answer the question in the title, you need Dependency Walker. (The web site doesn't mention Windows 10, but this stuff hasn't changed much recently, so don't worry about that.)
To distribute the program to another machine, you need to create a release build (the debug run-time libraries are not redistributable). Once you have done that, you will almost certainly find that the other machine already has the release run-time library, but you will need to copy other libraries.

How to run console-based target for a library project? [closed]

Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 8 years ago.
Improve this question
I am attempting to create/build/run a second target for a library project in xcode. The library is being consumed by another project in the workspace, and I have:
Created the second target, a console app
Confirmed that the generated main.cpp file is included in the
console target
Cleaned and rebuilt, confirming that the library still builds and
works
However the console target remains unbuilt. I have not received any errors.
Places I have researched looking for higher resolution steps:
Googletest xcode tip (meandmark.com)
Google test project target docs (per my use case)
Should I be using one project with multiple targets?
Build static library target with main target for...
Xcode concepts
Xcode help docs
If you think you can help, I'd be much obliged.
It might not be the answer you are looking for, but if you are new enough to XCode, that setting up a test.cpp to your library is challange enough, you might try another tool that in the long run might prove to be more useful.
CMake is an excellent cross-platform tool that is capable of generating platform-specific makefiles or project/workspace files for various IDE-s, including XCode. So you need to learn only one tool, and you're good for all platforms and compilers.
CMake has a companion app that ships with it, CTest. It is meant for just the thing you are looking for. It basically adds build targets that build a certain app (test.cpp in your case), and check if the return of int main() is zero or not. Multiple tests can be created (all testing different aspects of your library), and CTest provides nice interface to run all tests, just the specified ones and what not, plus it prints runtime of tests and shows which have failed.
CMake and CTest have good documentation, and there are myriads of tutorials available online. It might take some time to master, but in the 2 days time you spent googling, you could've ported your workspace to CMake easily. In the long run, it pays off.

Is there an equivalent of Make on Windows? [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 7 years ago.
Improve this question
I develop on Windows, and I'd like to use beanstalkd. It's only available as a tarball, and I was just wondering if there is some way to easily build it like you can in Linux? I found some ports of gnu make for Windows, but they don't seem to be working. Are the source distributions somehow specific to Linux?
When I try to use mingw32-make it says "Nothing to be done for file". TBH I wasn't sure what to run it on, so I tried the tarball, the directory, and Makefile.in and Makefile.am. They all say the same thing.
Make is available in cygwin, which you can install make via the installer.
The package is called "make", which is under "Devel" category.
I found some ports of gnu make for
Windows, but they don't seem to be
working.
Here are a few ports of GNU tools to Windows:
GnuWin32 - http://gnuwin32.sourceforge.net/summary.html
Gnu Tools for NT - http://www.devhood.com/Tools/tool_details.aspx?tool_id=3
GNU Utilities for Win32 - http://unxutils.sourceforge.net/
I am pretty sure I have used some of the utilities from the unxutils port without problems.
I would also look into using msys with mingw (it also can be found at http://mingw.org) I could try to explain it but I think the description from their page works better
MSYS: A Minimal SYStem providing a POSIX compatible Bourne shell environment, with a small collection of UNIX command line tools. Primarily developed as a means to execute the configure scripts and Makefiles used to build Open Source software, but also useful as a general purpose command line interface to replace Windows cmd.exe.
One bonus of using msys over cygwin is it builds native windows applications rather than having to rely on the cygwin compatibility layer
Most unix source packages require you to run "configure", which reads some info about your system and builds the Makefile - although in the early days of X11, some packages used "xmkmf" to build Makefiles out of IMakefiles. Only after thats done can you run "make" and possibly "make install". From the sound of it, you don't have a Makefile, only the Makefile.in (which is input to configure).
Cygwin is nice, as the previous answer indicated, but it includes a lot more than just make.
I used to use NMake on Windows to build Perl modules. Check it out:
http://johnbokma.com/perl/make-for-windows.html
That's useful for Perl. Looks like there's a general GNU port, too:
http://gnuwin32.sourceforge.net/packages/make.htm
Cygwin and mingw come to mind.
MSVC includes nmake which kind of works on regular makefiles with some tweaking.
The make utility expects to use a file named Makefile. If you just type make, it will find that file automatically. If the makefile has some other name, use the -f option. If you just give the file name without -f, then make will interpret it as the target that it should figure out how to make.
A lot of tools that only come as source assume that you'll use Visual C++ to build on Windows, even if they assume you'll use G++ everywhere else. Look for a Visual C++ makefile; it's usually named Makefile.mak. Then run nmake.
But if you only have files named Makefile.in and Makefile.am, then you don't yet have a makable environment. Makefile.in is one of the inputs to the configure script, which will construct the real makefile and maybe a header or two that are specific to your environment, based on tests that configure runs.
In the end, the package you've downloaded might not really be compilable on Windows. Even under Cygwin, you can expect to have to make a few changes to the source code if it hasn't been written with Windows in mind.
Makefile.in will contain the basics of the final makefile. Back before I knew what I was supposed to do, I simply renamed Makefile.in to Makefile and got pretty far. You can try using that file as a starting point for constructing a real Windows makefile, for whichever compiler target you choose. It will take patience; just keep following the compiler messages until you don't see any more. (And then comes the linker. Hope you don't need too many other libraries!)
Concerning the alternatives, check out this link. As far as your problem with make, you'll have to be a little more specific about the non-working part. What doesn't work, how does it manifest, what error it gives and such.
Let someone else do the hard work. Here's a precompiled beanstalkd 1.4.6 exe.
Decompress the tarball, cd into its topmost directory and type 'make'. Make will pick up the Makefile automatically.