Configuring ANTLR target output location with VS2010 - visual-studio-2010

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.

Related

How to include all of a project's output in the installer project?

I need to include all the output from some of the programs projects in the installer... my question is similar to the one in this post: How to add a whole directory or project output to WiX package
However, I am afraid I don't really understand the answer given in this link. From all the reading I have done, I think I need to use Paraffin to do this. But is there a "start from the very beginning, how-to" resource for using paraffin?
I have read this page: http://www.wintellect.com/CS/blogs/jrobbins/archive/2008/12/22/paraffin-3-0-now-with-full-wix-3-0-support.aspx
and one of the posts mentions calling paraffin from a bat file. Is this how one would "use paraffin" in their installer? If it makes a difference, I have been using Visual Studio to work on this project, and am also not sure how to use command line from within Visual Studio. Does anyone have any resources for a very new beginner? Thanks.
I ended up including each .dll and .exe manually, since they don't change very often. It was fairly easy to format them in this style:
`<File Id="WhateverId" Name="NameToDisplayAfterInstall" Source="$(var.ProjectName.TargetDir)Filename.ext" />`
I used Excel to format a list of files quickly and easily. I put all of these File tags in the <DirectoryRef Id="INSTALLLOCATION">
tag.
I did figure out how to scrape all the dlls and exes from the project output by using Heat (not paraffin) and harvesting a directory, not a project. Harvesting a project yields only the main exe and dlls. The problem with harvesting a directory, at least in my case, is that I ended up with a lot of excess files, (like .pdb and .xml) that I didn't want.

OpenGL SDK How To Create New Projects With Premake

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.

Visual Studio does not honor include directories

I have been in this situation quite a few times where visual studio does not honor the Additional Include Directories when it comes to lib and header source files. For example, I just downloaded MyGUI source code and made sure the include directories were correct. I even put them to absolute paths, Visual Studio still complained that it could not find specific header files.
Does anybody experience the same thing with projects, and if so, is there a solution to this problem?Blockquote
EDIT: My apologies for not being able to explain fully. I know that the library and source files have different include directories. The project that I received had correct directory paths for the Additional Include Directories and Additional Library Directories but Visual Studio still failed to recognize them properly. I can right click and open the header file within Visual Studio but when compiling it still complains it cannot find the required header files. I regularly make projects relying on a framework I myself programmed, so I am quite familiar with how to set up dependencies. This is however the second time this seems to be happening. I don't recall which 3rd party project I was trying to compile last time, but Visual Studio simply refused to believe that the Additional Include Directories paths is where it should look for the header files. I am not sure how to give the complete details of this particular library (MyGUI) but I can point you to the website where you can download it to try and see if it is able to find the header files that are included in the project (if it doesn't compile, that is fine, and it is probably because of additional dependencies, but it should at least be able to find files in the common folder, especially when I put absolute paths in Additional Include Directories)
This happened to me once. It turned out the inconsistency of the Debug vs Release builds. When I modified one build, the other build was being compiled. Please set both builds with same include folders and see if it works. Good luck.
I've just spent some hours battling with failing #include paths in the compiler, inconsistencies between the compiler and intellisense.
What I finally discovered was that in the properties of the *.cpp file -- not the project, but the individual *.cpp file -- the "Additional Include Directories" property was blank. I had to explicitly set it to "inherit from from parent or project defaults" -- there's a checkbox near the lower-left corner of the dialog for editing the directory path.
I had copied this file from another project and used "Add > Existing Item..." to add it to the current project. My hypothesis was that maybe the "Existing Item" procedure skipped a property initialization step that "New Item" would normally perform. But I just tested that hypothesis by Adding another Existing and a New. Both of these files had their property set to inherit from the project, so I don't have an explanation for why my problem file was not initially set to inherit.
Anyway ... after much frustration, found and fixed that one.
I have found (stumbled) on the solution (I think). It has something to do with the character limit imposed by the OS. Although the limit should be 260, for me it falls in the below 150, see this discussion and links to it. I downloaded and unzipped the file to C:\Users\MyUserName\My Documents\Downloads\Downloads From Chrome\MyGui3.0...[and so on]. I learned quite some time ago not to try to compile projects under such long paths, but this time it completely slipped my mind as VS did not give me a warning at all and pointed me in the wrong direction. Anyway, cutting and pasting the project to D:\ fixed the issue. I am not going to checkmark the answer however until someone confirms this.
I have the same problem : Can't find .lib file even though I've added the additional include directory.
From an answer of Additional include directory in Visual studio 2015 doesn't work, I tried:
delete the .suo file and restart VS
Then it works for me.
I had this issue too. Just like sam said - this string value containing path to your framework includes has to be the same for the Debug and Release configurations. So the best way is to choose "Configuration:All Configurations" and "Platform:All Platforms" from the two context checklists on the top of the project properties window before typing it in, or copying from windows explorer adress bar.
Can you elaborate on this? If I recall, there are at least two places in Visual Studio where you can configure this:
Per-installation: Tools/Options/Projects and Solutions/VC++ Directories)
Per-project: Project/Properties/Configuration Properties/"C/C++"/General/Additional Include Directories
If you're adding the include directories per-project (#1), which I think you are, and then trying to include from another project, this will obviously not work. Try adding them at the per-installation level and see if it works.
Also, this may sound stupid/simplistic, but make sure the path is right (i.e. copy-paste into Explorer's path bar and see if the header files are in that folder).
If by lib files you mean library (.lib) files, the directory location is not specified through C/C++/General/Additional Include Directories but rather through Linker/General/Additional Library Directories.
It's logical if you think about it. C/C++ options are all compilation options, settings involved with compiling .cpp and .h files. Linker options are all linking options, settings involved with linking up .obj and .lib files.
I had the same symptoms in my c++ project. Navigating from header to header went fine, but after toggling to the source file of a header (let's say foo.cpp), then the navigation to an #include <bar.cpp> in that source file failed. I got the following error:
File 'bar.cpp' not found in the current source file's directory or in build system paths.
After research I noticed that the system build path given in the error where not extended with the include paths of the project. In other words: IntelliSense didn't know that the source file (foo.cpp) was part of the project, and therefore it didn't use the include paths of the project to search for the #include <bar.cpp>.
The fix for me was creating a file intelliSense.cpp (file name doesn't matter) that is part of the project, but excluded from the build. This file contains an include for each source file. ex:
#include <foo.cpp>
#include <bar.cpp>
...
This way IntelliSense knows that these source files are part of the project, and will therefore use the include paths of the project to resolve the #includes in those source files.
For me the issue was that .vcxproj Project file was read-only and after I added my directory to "Additional directories", the project file did not actually change. I was surprised that VS did not complain about this file being read-only.
So after I made that file write-able I could compile my project.
Here is another 'I had the same...' in vs2015.
For me it turned out that the active setting is also depending on the 'solution configuration' and 'solution platform'. That makes 4 settings which all should be identical.
That solved the problem in my case.
I realize this question is over 10 years old at this point, but I also just ran into this issue and none of the answers fit my scenario. After some playing with my IDE (VS 2019) for a few minutes I realized that the cpp file I was using had it's platform set to Win32, but the libs I was trying to use were built for x64.
As others have stated, make sure your project's configuration is set to
-"All Configurations" when you add the necessary paths to your project as that can also be an issue. I imagine my issue will not be as common, but I figured it was worth sharing. I hope this helps someone else in the future.
One more possible reason not mentioned earlier: make sure you are configuring properties of the correct project in a multi-project solution.
My problem was that I had a solution of two projects each using the same file with includes. Turns out that I correctly configured 'Additional Include Directories' only for one of two projects and totally forgot about another one. Of course error message was stating that only the second project and not the first one had problems.

Boost 1_44 includes don't work

Sorry for what seems like a silly question: But I've never, ever worked with boost, until tonight, and I'm finding that getting it configured seems to be harder to use than it should be.
I wanted experiment with it tonight. So I downloaded the zip file, and unzipped it to a directory here:
F:/boost_1_44_0
Then I created an empty c++ project in visual studio 2010 (not using pch either). So all I wanted to do was to include a header file. But not even a silly thing like that seems to work. Now I've been using visual studio for years, though at work we are still stuck on vs 2008 (That is another story). So usually what you do is set an include directory, and then you can include files in at will right?
So I set the global include directory to include the boost root. i.e. Property Manager -> My configuration (debug|win32) -> Microsoft.Cpp.Win32.user -> Common Properties -> C++ Directories -> Include Directories. There I added my path to f:/boost_1_44_0.
I also went to the project properties and set the C++ include directory for the project to point to the boost root like in vs 2008.
I then added a silly include declaration like so:
#include <boost/lambda/lambda.hpp>
But, amazingly it fails to compile!!! with the following error:
Error 1 error C1083: Cannot open include file: 'boost/type_traits/transform_traits.hpp': No such file or directory f:\boost_1_44_0\boost\lambda\core.hpp 25 1 test_boost
Which when I double click it, it opens up in f:\boost_1_44_0\boost\lambda\core.hpp, and takes me to this line:
#include "boost/type_traits/transform_traits.hpp"
So I have no idea what's happening. Is visual studio just not delivering up my global include paths that I set? It seems also that the include directive in core.hpp should be using angle brackets and not quotes.
If I'm doing something wrong what?
EDIT:
!! SOLVED !!
Before I didn't have all the files unzipped. I don't know what happened. So I re-downloaded the zip file, and unzipped it again. This time the zip file took much longer to unzip, and it extracted much more files: Including the missing files.
Problem solved, my hello world app compiles just fine now.
The behaviour of compilers in locating header files is implementation defined for both the <> and "" variants.
However, based on this page for VC2010, it appears the quoted form searches a superset of the angle bracket form so I'm not sure that's the problem.
I suppose it would be a silly question to ask if the following file actually existed?
f:\boost_1_44_0\boost\type_traits\transform_traits.hpp
So, a couple of investigative jobs:
Make sure that f:\boost_1_44_0\boost\type_traits\transform_traits.hpp exists.
Try changing your top-level include to use quotes.
Try changing the include in f:\boost_1_44_0\boost\lambda\core.hpp to use angle brackets.
Make sure you try all four possibilities for those last two.
Is f: a network-mounted drive? What happens if you put it all on c:?
That last one is just in case Windows is doing some shenanigans under the covers :-)
While it's a bit overkill for this, learning to use SysInternals' Process Monitor will pay off over time. It will show you what files are actually opened, and which attempts failed. Look where Visual Studio tries to read transform_traits.hpp from, and you'll probably have the answer.

VS2008 files and "start debugging"

This may sound like a newbie question - and it is. I'm relatively new to vs, we started using it a few months ago, and I still haven't "mentally" made the change from the command line. So, if you could help me with 2 things:
I create a new project (not a solution). He puts the files in some directory. After putting my code inside it, I click on the little green triangle (Debug, it says), and he compiles it, builds it and runs it. It works ok. Now, sometimes, I have to change only a tiny bit of code and I don't feel like getting the whole VS up just for that. How can I do that Debug thing from the command line, with the assumption I didn't change anything else.
Where do I tell him not to create a "Debug" subdirectory, not to create a HTML Build log, an object file ... and so on, generally, where can I find the settings which will help me to get as little files ... apart from my original source, and the .exe resultant one ?
I have to change only a tiny bit of code and I don't feel like getting the whole VS up just for that. How can I do that Debug thing from the command line, with the assumption I didn't change anything else.
I think what you want here is not debugging but a rebuild of your project.
Where do I tell him not to create a "Debug" subdirectory, not to create a HTML Build log, an object file ... and so on, generally, where can I find the settings which will help me to get as little files ... apart from my original source, and the .exe resultant one ?
The answer to both these questions is to use the command line! You can make VS emit a make file from the loaded project. Use NMAKE to build this make file after you have made your desired modifications. The ".obj" files are created as an intermediate step between compilation and linking phase this is how the C++ compilation model works. Why do insist on not generating them?
You can't really start debugging without starting up Visual Studio, since Visual Studio is the debugger. You can tell VS to rebuild a solution from the command line without firing up the UI if you want to just build it: See MSDN for details.
You can control the creation of the DEBUG and RELEASE directories via the 'intermediate files' option in the project settings. Though you need to create the obj file somewhere in order for the compile to work.

Resources