I'm relearning C++ after many years of higher-level languages. I've been googling around in circles for a while now on this. One issue with googling for answers in C++... "how do I include .h in my build output" just returns a bunch of results on how the #include statement works (not quite what I was looking for google... thanks...).
In visual studio, when I run a build, the output folder contains
mydll.dll
mydll.tlb
mydll.xml
I know header files are required to import the DLL into another application, but I'm not sure on the process.
Do I just copy/paste the .h files into the output folder? What's the canonical way to automate this process in VS?
Is there some step I should be taking that adds them to the output?
Should I really be shipping it with multiple .h files, or is there some way I'm supposed to combine them into one large mydll.h file?
Am I correct in my understanding that .lib is only generated if something in my library is static?
Is there a good guide for creating a production build somewhere out there?
I appreciate the advice!
Related
From this question's answer, it seems as though this should be simple: How do you include LuaPlus into your project?
This is absolutely ridiculous though. It is so dumb that you have to build this (along with such an awful website), but there are absolutely no tutorials on this either. Horrible documentation on getting it installed.
I read something about building it using the "jam" stuff, but that is alien lingo to me and sounds asinine. Why not just make this simple? Most libraries just let you download them straight up, extract, link, and wallah! I've built libraries before, and it was extremely simple and easy.
Anyway, I successfully built the library in Code::Blocks, but that isn't the problem. The problem is it only builds the library. Where are the header files to add to the include directory?
I tried messing around, but I had errors just dumping what I thought the header files were into a directory and including it.
I read online, people who use Visual Studio to build don't have a problem, and it creates all the header files. The only thing that results from my Code::Blocks build is the library file.
This is a PITA just to get to use, and I've already been at it 2 hours and the only way I can work with it is if I include the entire source in my project (which is just ridiculous).
edit2: Ergh! LuaPlus edits Lua itself, so you have to remove your link to Lua. LuaPlus has Lua in it. So F***ing ridiculous. Just let people download the library and just link simply for god's sake. A huge middle finger to needlessly complicated crap.
edit: Nevermind, this isn't the correct answer. Now I'm getting all kinds of stupid errors.
I guess the first time I copied over all the header files, I did something wrong because now it works just as it should.
For anyone interested, you just copy/paste all of the header files (shown here
Minus LuaPlusAll.cpp, src/lua.c, and src/luac.c
Then paste them in your search directory
lib/libLuaPlus.a
include/[paste here]
Link the library & include directory, tell Code::Blocks to use "libLuaPlus" and wallah!
No idea why I had problems with this. Must have been following someone's bad directions (causing me to mess up somewhere).
I am currently trying to build .net bindings for a very large project that is written in C an C++. The project was recently ported over to Windows, and I might add that is is a big giant mess.
The solution has about 12 projects, which is fine but the directory itself has alot more files than needed,since it includes OS specific source files, demo projects etc.
Also the other thing is the headers and source files are scattered all over the place. I am working on a parser to help me create the bindings for this project, but I am having a heck of a time. Especially when the internal include references are completely off.
The developer did a great job porting this large project to Windows, but isn't very organized and it is driving me bonkers with the issue my parser is having. So the easiest thing to do would be to re structure and put each project in it's own areas.
So as I asked in the title, is there somewhere that I can export each project and it's files from VS 2010(or another tool) so I can begin restructuring the folders? When I have ever needed to do this before in .net it was easy enough to just move the files. In smaller c++ projects I just open up the project file in notepad++ and move each file in the include/source list into different directories and changed the paths in the project file after. The issue with that is it will take way too long, and I have already spent days messing with this project, finding the best way to wrap it, and creating my helper tools.
Can anyone give me some assistance in this aspect?
EDIT:Just to clarify, I would like to export each project into it's own root folder with one folder for headers and one for source files so I can keep things simple.
I'm not sure about a tool for this, but the .vcxproj project files are in XML format, so you can easily extract a list of files from each project. Then you could relocate those files and write their new location back into the project.
Whenever I encounter a serious project mess, I usually end up dragging all the project files into Notepad++ and start doing global search and replace.
I haven't done it on the scale that you seem to be aiming at, where it involves relocating all the sources. You could be in for a rough ride. Fixing up include paths etc could be quite a pain.
I suggest you obtain the file lists (relative paths or whatever) in a simple text format, and then decide whether you want to take the red pill or the blue pill =)
I have a c++ project with many files. When I build the project making even small changes to the code, It recompiles a large no of files. This is increasing the compile time of the project. So I need suggestion about the ways I can improve the structure of the project or any other optimisations possible which will help in reducing the compile time of the project.
Also there are a couple of files which are getting recompiled even when I make no changes to the project. Somehow make doesn't detect that those files need not be recompiled or may be I am missing something.
I am using Codelite on linux(Ubuntu) for my project. The language is C++.
The link provided above will give you a detailed explanation. Just to put it in a lighter way I am adding a few more things.
If you change something in a CPP file only that file will get recompiled. If it is a header file then it will be a different story. If you have a header file included across multiple modules and when you make changes to that header file, all the associated CPP files will get compiled and again that is the way it should be. So you need to be careful while writing the code if you really care about this aspect. At a later stage it will be difficult to manage such things.
Regarding the compilation of some files even if you don't change anything may happen when
1] we tell the compiler to do so.
2] some CPP or header files are generated or modified automatically while run your build
3] there is a change in file time stamp
4] there is a change in folder name/structure
Last but not least, also try changing the code lite build target.
These are the possibilities I know. There will be more [definitely :)]...
I'm a beginner starting to use Microsoft Visual C++ Express 2010 for Windows Programming. I've created a new C++ application using native code, not managed or MFC. I had Visual Studio create for me the basic windows code to create one window with simple menus (chat.cpp). I modified this file and I was able to compile correctly and see my changes take effect.
Now I've added one more source file to the solution (intro.cpp) which I include in my header and call from within chat.cpp. This seems to work just fine, but with one problem. The compiler doesn't seem to be applying my code changes occasionally: I make various edits, recompile, and the "old" code seems to be running. Then, after a while, after I make only a tiny modification, the compiler seems to "catch up" and it runs the new code including all the previous changes I had made.
Is there some kind of cache? Do I need to tell the compiler which files to compile and which ones to just link from object files? Did I make a mistake when I added the file to the solution?
Does intro.cpp have a header file? is that in your solution too?
It's hard for me to imagine that this area of such a mature IDE has a bug here, so I would examine your file list first. Make sure that the Solution Explorer shows all the files you have added and are editing. This is the list that VS uses to determine rebuild is needed.
EDIT: I admit it's not clear to me from your description why it would fail right now. However, typically header files do not include code, it works the other way around (except for class template header files, such as the STL headers). There is some discussion about pros and cons here. The most compelling argument to me in favour of code including headers rather than vice versa is that the header file contains the interface, while the code file contains the implementation.
I would try restructuring your code to a more traditional structure where intro.cpp includes intro.h and any others it needs, and the same with chat.cpp. Then your compilation units are intro.cpp and chat.cpp, and they depend on the associated header files, so provided they are properly listed in the SOlution Explorer, all should work. You can clean up the build dependencies to avoid dups and reduce build time once you have it working as you wish.
In some of my VS 2005 projects, when I change an include file some of the cpp files are not rebuilt, even though they have a simple #include line in them.
Is this a known bug, or something strange about the projects? Is there any information about how VS works out the dependencies and can I view the files for that?
btw I did try some googling but couldn't find anything about this. I probably need the right search term...
I've experienced this problem from time to time, and with other IDEs too, not just VS. It seems thatv their internal dependency tree sometimes gets out of whack with reality. In these cases, I've found deleting pre-compiled headers (this is important) and doing a complete rebuild always solves the problem. Luckily, it doesn't happen often.
To be honest I never faced such a problem using Visual Studio. Your CPP should be rebuild as well if it includes the header. The only reason I can come up with: same include file is taken from 2 different sources.
You can try do debug this at compile time, by enabling the preprocessor to output preprocessed files. Click on the CPP file go to properties and then to C/C++->Preprocessor and select in "Generate Preprocessed File" the item with or without line numbers.
Go to you include file put the pragmas around your newly added definitions like:
#pragma starting_definition_X
...
#pragma ending_definition_X
Now compile everything. There will be a newly created file with the same name as CPP but with extension .I (or .i).
Make a search if your pragmas are there. If not, your include come from another place.
If you use pre-compiled headers, you cpp should rebuild. There is also a pragma once statement in MS VC, which parses the include file only once, but that should still recompiler you cpp-file.
Hope that helps,
Ovanes
Do you have the "Minimal rebuild" option turned on?
Visual studio compares the timestamps on the files. So you might want to check that your system clock is set correctly and also that none of the files has a funny timestamp on it. Look at the include files, the cpp files, the pch files and obj files and make sure all the timestamps look reasonable. In particular, make sure none of them are in the future.
Was the .h files added in the project? If not, then vs maybe unable to find out the dependency.
Thanks for all the answers they have helped point me in the right direction.
I have discovered that deleting the idb file and rebuilding will then allow subsequent modifications of .h files to cause the correct .cpp files to be built. However this causes the entire project to be rebuilt which just brings me back to Neil Butterworth's suggestion of doing a full rebuild. I don't think there is much else I can do about it.
As an aside, looking at the bad and good idb files I can see that the cpp file that was not being built is not in the bad idb, whereas it is in the good idb. The header file that is being changed is mentioned several times in both files.
win_pdbx (download) can extract the idb file and moyix has published some information about the streams in these files.
Stream 4 contains the file paths of the cpp files but I have not been able to determine the format.