I have recently begun the process of learning OpenGL to start making some Graphical applications using C++. I have installed the OpenGL SDK and I am able to build the projects properly on that. However, on the OpenGL SDK site there is little to no information what-so-ever on how to create new projects using the elements of the SDK, such as freeglut etc. I have Premake 4.0 and I understand I have to do something with the lua files, I do not know lua however and am not sure how to use the Lua files to create a new project. So could you help me out? Im using VS2010, should I create the project, then do something with premake? Or create some sort of lua file, then use premake on that? Any help would be wonderful because I am very lost, and would really like to get started with OpenGL. I have experimented a lot with this, such as copying the lua files from the sdk, but that came with no luck.
If you are not familiar with Premake4, then I strongly advise you to just use Visual Studio projects directly. If you're having trouble with that, then please amend your question with exactly what you did, and exactly the error messages that Visual Studio gave you when attempting to build. You should include:
The include paths. The full set of include paths, including full absolute directory names (including the path of your project and solution files).
The static library search paths.
The static libraries you are including.
The defines you are building with.
Note: If you don't know what any of these are, then you need to stop and learn a lot more about how C++ projects work. You need to understand how compilers deal with include paths, static libraries, #defines, etc.
If you are not familiar with Premake4, and you still want to use Premake4 with the SDK, then you first must become familiar with Premake4 without the SDK. I could give you an entire premake4.lua script that you could just plug in, change a few lines, and everything would magically work (and if you want that, you could look at how the SDK's examples are built. Specifically examples/premake4.lua). But if I did that, you wouldn't learn anything. You'd just be copy-and-pasting code, without having the slightest understanding of how it works.
So instead, I'm going to tell you what steps you should take to learn how to use Premake4.
Step 1: Hello World, Premake-style. You should make a single .cpp file that is a Hello World application. It just has a standard main function that prints "Hello World" to the console. That's the easy part.
The hard part is the Premake4 script. Rather than creating a Visual Studio project directly, you are going to write a Premake4 script to build that project for you.
The Premake4 documentation can walk you through the steps of making your first solution and project. You will of course need to add files to that project. You should also learn how to use configurations, so that you can have a Debug and Release build. The Debug build should have symbols, and the Release build should be optimized.
Step 2: Multiple projects. Here, you have two .cpp files: test.cpp and main.cpp. In test.cpp, place a function that prints something. The function shouldn't take parameters or anything. In main.cpp, you should have the main function that calls the function defined in test.cpp. There should also be a test.h which has a prototype for the function defined in test.cpp.
The trick here is that you aren't compiling them into the same executable. Not directly. You want two projects: one named test and one named main. The test project should be a static library, which compiles test.cpp. The main project will be the actual executable, which compiles main.cpp. Both of them should include test.h in their file lists.
Here, you're learning that solutions can have multiple projects. The two projects have different file lists. Each project can have a separate kind, which determines the type of build for that project alone. The test project should be a StaticLib, while the main project should be a ConsoleApp.
You will also need to learn to use the links command to link them together. The main project should use links to specify test. test does not need to link to something.
Step 3: Mastering directories.
Here, you're going to do the same thing as Step 2. Except for one thing: put test.h and test.cpp in a different directory (a subdirectory of the current one). You also want a test.lua file in that directory, which you will execute from your main premake4.lua file with a dofile command. The test.lua is where you define your test project. You can call dofile on the test.lua file anytime after you have created the solution with the solution command.
Note that the main project will need to change the directory where it finds test.h. You will also need to use the includedirs command in the main project to tell the compiler where to search for the test.h header you include in main.cpp.
Step 4: Back to the SDK. At this point, you should now be familiar enough with Premake4 to look back at the instructions I pointed you to and understand them a bit better. Then, just do what the instructions say. When it tells you what the first line of your script should be, make that the first line of your script. Put the UseLibs function where it says to put them; it even gives you an example of where it goes. Think of UseLibs as a fancy combination of links and includedirs.
Related
Lets consider a project, with a following structure:
project
--main
--fileX.h
--fileX.cpp
--main.cpp // only file, that guranteed to have main()
--libA
--libA.h
--fileX.cpp
--fileY.cpp If they are outdated/not built - build them first
--libB
--libB.h
--fileZ.cpp
--fileW.cpp
Pretty simple, also lets consider that project must include and link something standart, like OpenGL lib.
On windows, where I came from, there is Visual Studio, and everything was extremely easy and in some kind of "standart" way:
You create solution project. This is like a root, which just incorporates projects, in a single tree
You create projects: main of type "binary" and a couple of libs libA, libB of "library" types (static or dynamic, whatever you require to). That will tell build system how should it glue them together
You edit main settings:
Add external include and lib names, and paths
Add dependencies. main requires libA and libB. That is simultaneously a hint on build order, plus a linkage hint
You add files here and there, code it all, make any changes.
Press debug/run and enjoy. Build system would (re)compile only nesesary files, and link everything needed
Everything involves less than 100 actions, I mean keystrokes and mouse clicks.
VS Commutiny IDE is totally free to use (so no "Use that cool paid IDE" offers could be made in comments and answers)
Now the question. I've installed Ubuntu and vscode, and I am running into wall, trying to setup same project. What actions should be done, so I am able to change any source file in the project, press F5 (Debug), and it would compile and run with same build setup and speed efficiency?
What I've considered?
Makefile: almost same as writing your own shell script. It's like you have to learn whole new language to do small pretty-standart task - build a project. High leven of entrance, to be good at it.
vscode launch.json/tasks.json - another language, with examples availble to compile only single file: main.cpp (or just active file). Hard to create manually, requires good knowledge of internal "env" variables
CMake - another new programming language, different from all others, don't even know how to make vscode and Cmake friends
How a beginner should start C++ debuging with a multi-lib project, without having to waste time maintain that infinite complex build systems?
I am new into software developing. I have found this GitHub repository which I plan to modify. Let's just say I fork this repository and modify it. How would I then be able to export it from there. By export it I meant turn all of those files into one windows executable file. Thanks.
In general, building a project is a project-specific task unless the project is written in a language (such as Rust) that has a built-in build tool. If you're unclear about the steps to build a project, you should look in the documentation or the wiki for steps about how to do so, and failing that open an issue asking them to document the procedure for building the project.
Just looking at the project, it does not seem obvious that it should produce a binary executable of any sort since it's written mostly in JavaScript.
Usually you use a compiler to turn source code into machine code (exe files).
As bk2204 mentioned, this project is based on Javascript and Node.js.
Javascript is interpreted instead of compiled, so another program (Node.js) reads the source code and executes it directly every time instead of first compiling it into an exe file. That other program itself may be in an exe file.
The project you have linked is a fork of this project, and that one seems to have a Windows launcher/installer exe file (that probably installs or contains Node.js, but I haven't checked).
That installer is available here in both exe and source code form. So you could modify the launcher and rebuild it, but the main app is not in the launcher, instead it's in all the JS files. You may be able to edit the JS files and just use the same launcher without modifying it. There may be a packaging step required after editing the JS files, to package them into a form that the launcher expects. You would need to run this build step after every time you modify the JS files, to provide the new code to the launcher.
You would have to explore the project's structure and build process to find out the exact steps.
If you're very new that may be exceedingly difficult.
You may want to practice by learning Javascript and Node.js.
You could after that try Java which is compiled, and possibly more powerful than Javascript. Just for fun.
Maybe you could do 30 of these practice projects, then you'll have a chance of being able to modify this project successfully.
I am new to ANTLR. I wanted to learning start by setting up a project so that lexers\parsers would be automatically generated by the build. So I downloaded antlr-dotnet-tool package, modified a project file to include antlr targets. I also installed some VS extension that add syntax highlighting and new item types for grammar files.
Now, generation seems to works, but it puts output files into obj/${Configuration} folder. And I don't really know what I am supposed to do with them there. Surely, you don't want me to manually copy them to proper locations (supposedly next to grammar files), do you?
It would be great if you could shed some light on it.
If you followed my blog post, you will see that you need to do nothing else,
http://www.lextm.com/2012/07/how-to-use-antlr-on-net-part-v/ (note that at the beginning you will see links to the previous 4 parts)
At compile time the generated files are automatically linked to the output assembly, and the debugger is capable of loading them when you debug the program.
I am trying to compile the following software so that I can step through and debug it. I am only a novice programmer and I am trying to understand how this whole makefile business works with Fortran. I know that there is a ton of literature on makefiles but I just need to insert a simple debug flag and I think if someone provided me with the answer to this question that would be the best way for me to learn.
So the program I am trying to compile, TINKER, is actually made up of several packages, located at http://dasher.wustl.edu/tinkerwiki/index.php/Main_Page. I would like to compile and debug JUST ONE specific executable, "analyze". I contacted the developer and received the following reply but I am still stuck...
Since TINKER has lots of small source code files, what we do is
compile each of the small files to an object file using the "-c" flag.
Then we put all of these object code files (ie, the ".o" files) into
an object library. Finally, we link each of the TINKER top level
programs, such as "analyze", against the object library. There is a
Makefile supplied with TINKER that does this. We also supply
individual scripts called "compile.make", "library.make" and
"link.make" for various CPU/compiler combinations that can be run in
order to perform the steps I describe above. To build a "debuggable"
executable, you just need to include the appropriate debug flags
(usually "-g") as part of the compile and link stages.
I am currently running OSX 10.6.8. If someone could show me which folders I cd into, what commands I enter that would be so great!
Thanks!
My follow up question (once I can figure out how to answer the above via command line will concern how to import the same procedure but using the Photran IDE - http://wiki.eclipse.org/PTP/photran/documentation/photran5#Starting_a_Project_with_a_Hand-Written_Makefile)
The directions are at http://dasher.wustl.edu/tinkerwiki/index.php/Main_Page#Installing_TINKER_on_your_Computer
Maybe out of date? g77 is obsolete -- it would be better to use gfortran.
The key steps: "The first step in building TINKER using the script files is to run the appropriate compile.make script for your operating system and compiler version. Next you must use a library.make script to create an archive of object code modules. Finally, run a link.make script to produce the complete set of TINKER executables. The executables can be renamed and moved to wherever you like by editing and running the ‘‘rename’’ script."
So cd to the directory for the Mac -- based on "we also provide machine-specific directories with three separate shell scripts to compile the source, build an object library, and link binary executables." Then run the command scripts. Probably ./compile.make. Look around for the directories ... you can probably figure it out from the names. Or search for the file "compile.make".
Or find someone local to you who knows more about programming.
I've inherited some C99 code that I'm planing on reusing in a C++-centric solution. Unfortunately, even Microsoft's latest compiler has virtually no support for non-trivial C99 features.
The code in question has been tested to death and I'd rather not go through the trouble of rewriting it in C++. This means that in order for me to reuse the code verbatim I'll have to rely on a conforming 3rd-party compiler.
After looking around, it appears that the nicest way for me to integrate this code is by adding a "Makefile Project" to my solution. Only one problem. It seems like it is now my responsibility to keep the "Build Command Line" property synchronized with the files that I add to the project through Visual Studio.
At first glance, I couldn't find a way to get a list of files in my project through the usual Visual Studio $()-style macros. I could always write a shell script that would enumerate *.c files in my source tree and pass their paths to the 3rd-party compiler. However, I kind of expected that Visual Studio would do at least that part of the work for me since it already has this information in the relevant *.vc[x]proj file.
It is very unlikely that I'll need to add any new source files to this project, but still, manual synchronization (i.e., without a script) of this sort seems rather fragile to me.
What are my options besides writing a helper script?
From Hans Passant:
"Makefile project" means what it says,
there needs to be another 'agent'
that's responsible for the
dependencies. Like a make file. Rule
files can help you select another
build tool but that's kinda broken
right now in VS2010. Leverage the
original tool that built this C99
code, run it from the makefile
project.