I understand that .lib is static library linking and .dll is dynamic. This means that when .exe is produced, .lib does not need to be around for .exe to work. However, .dll need to be put in the correct relative path for .exe to reference and run.
My question is for .lib. When uploading the source code to Github, do I include .lib file in the project folder as well? What is the best practice in doing so?
Most of the tutorial that shows how to install library makes us link .lib file to its original folder and move .dll file into the working project folder. So should I move .lib file into my project folder as well? If I don't do that, it means the person that download my source code will have to go find the corresponding .lib file to link and compile right?
My own "IMHO answer" would be: "GitHub is concerned with source code." Therefore, I would not suggest including a binary .lib file there. And, I probably also would not put a binary .dll file there, either.
To clarify the difference between the two files ...
A .lib file is a library of object-code, resulting from previous compiles, that can now be referenced by the linker. The linker will choose whatever it needs, then copy these items out of the library into whatever it may be building at the time.
A .dll is a dynamic library ... "dynamic" in the sense that applications (and, other DLLs ...) can load it and unload it at runtime. (The Windows program-launcher also automatically loads any DLLs that are directly or indirectly referenced by anything it is launching.)
.dll's are "all or nothing." You load them in their entirety, at runtime. .lib's, by contrast, are true libraries, which are used only by the linker.
=== Edit: And the next Answer, IMHO, "nailed it."
Git repos are about code, and you should not have binaries in your git repos.
However, github has a feature called releases which allows you to upload binary assets alongside your tagged source releases.
You can add your compiled libraries there.
Your question is really about dependency management. Irrelevant of .lib or .dll, these are just different sorts of dependencies. Your question is if someone clones my repository, how can they build it?
The answer is you need a build script, makefile, rakefile, jake file, etc... something that the user can run to do the build. For instances this could be a README which says: "go download the files you need from website X". Alternatively you can do as you suggested an put the necessary dependencies within your repository. Legally this isn't always permitted as it is considered "redistribution". The best approach is to use some sort of dependency management. Depending on the language you are using there are different dependency management solutions. I would recommend only using libraries (.dll, .lib, .tar, .*) from public dependency repositories.
In Java, the recommended approach is using something called maven. Ruby has gems, node.js has npm packages. This is nothing more than a file with a list of dependencies, and a tool which knows how to retrieve them. To build my libraries it is as simple as running
npm install && node make.js which says run the nodejs package manager (dependency manager) to download all the necessary files, and then run the build script.
For C++ it could be something like make install && make which would require a makefile you configure to say these are the things which need to happen before the project can be built.
Personally C++ has poor dependency management, but that may turn out some negative responses, I'll just say dependency management in C/C++ isn't my favorite and for mostly internal software or small use I would still with committing the lib with your code. If there is a public repository which contains your lib files you could always generate a makefile/Cmake to curl or wget as part of the build process before you call gcc compiler.
Related
I want to package my executable file and other needed files into an install file (using NSIS) so that other people can install and use. There are a few file types I am uncertain of whether they are needed for installation or if it is safe to delete them.
Here is a random example of the files in the project folder as well as the Debug file automatically generated by VS:
I have already deleted the .user file as I know that is not needed, but not sure when it comes to .vcxproj, .tlog, .build.cppclean, .idp, and .pdb files. Also, do I need to keep the .obj files as well as the .cpp files?
This is my first time trying to do this, I am just messing around to seeing how it all works so thanks in advance.
You generally only need the .exe. Your app might depend on custom .dlls or the C++ run-time library in which case you would bundle the custom .dlls and/or the C++ redistributable.
Your screen shots are of a debug build and you normally want to distribute a release build instead because it is often smaller and contains more optimized code.
.obj files contain the machine code for each source file and is used by the linker when it merges all the required code into your .exe.
.pdb files contain debugging information. You should not distribute them but it is helpful to store them for yourself in case you need to debug a released version of your application.
The rest of the files in Debug and Release can also be ignored.
If your project is open source then you could include the c/c++ files and the Visual Studio project files. Or you could just upload them to Github.
In NSIS you could do something like this
InstallDir $ProgramFiles\MyApp
Page Directory
Page InstFiles
Section
SetOutPath $InstDir
File myproject\Release\MyApp.exe
File mylibrary\Release\*.dll
SectionEnd
It is a good idea to test your installer on a freshly installed Windows instance. Ideally the minimal version you require, Windows 7 etc. This should allow you to verify that you have included all the files required by your application.
To use C++ libraries we need to copy .dll files from bin folder, we are either instructed to paste them in the project directory OR in C:/windows32/.
Does it matter where we paste .dll files besides the scope of accessibility ?
It’s a very bad idea to write files to the system directory if you have an alternative. (And if you did need to, you’d check the environment variables instead of hardcoding.)
At best, no other program will install a library by the same name, so you’ll have a bit of extra junk in your system directory. It can’t be removed when you uninstall the program, because it was never registered and you have no way of knowing if some other application needs it.
At worst, two different programs will install different versions of FOO.DLL and one of them will break. This is affectionately known as “DLL Hell,” and the solution was for everyone to put their DLLs in the project directory. (Or sometimes, the vendor’s Common Files.)
I'm trying to write an application that wraps SVN. I've downloaded the binaries for it, and all I've found are DLLs.
Is there somewhere where I can find the .lib files? Or do I need to use LoadLibrary and find each method manually? Or do I just need to include the SVN source code, which would be a pain to maintain.
EDIT:
I have found a download that has all the .libs and include files after following this question, anyone else trying to find an answer should look here:
For anyone else who may be looking for the same thing, there is a download here that has everything you want!
Are there Windows API binaries for Subversion or do I have to build SVN to call the API from Windows C++?
I don't think that what you want is readily available as very few people use that. You are searching for a developer build for svn.
Your best chances are to download the source code for svn and compile it yourself. That way the lib files will be generated and you will be able to link against them.
EDIT : Another option you have is to use another layer of wrapper around SVN and use something like rapidSVN API. This will expose most common svn features and you don't have to handle the svn source code.
EDIT2 : I think that they moved to github
https://github.com/RapidSVN/RapidSVN
DLL's are libs, but they are dynamic libs, loaded and executed during run time. Lib files, however, are libraries that have been loaded into the compiler and used to compile the binaries. In your case, there wouldn't be lib files because the .exe binaries already have the libs built into them. Where-as, you do get the DLL's because they aren't built into the binaries, but instead are loaded somewhere inside the binary during execution.
There is no reason to include the .lib's in a binary download since the binaries don't need them anymore to function. The only reason you would need .lib files is if you had the rest of the source code in order to build your own .exe again.
I read this guide that walks you through the steps necessary to create a "visual" application with Cairo and Visual C++. The guide suggests you download certain dll files and store them in the directory in which your executable is created (debug).
Here is the list of the files Nil is referring to in his tutorial:
cairo Binaries (yes you need the binaries package too, as the Dev one doesn't contain the DLL) -> libcairo-2.dll
zlib Binaries -> zlib1.dll
libpng Binaries -> libpng12-0.dll
Freetype Binaries -> freetype6.dll
FontConfig Binaries -> libfontconfig-1.dll
expat Binaries -> libexpat-1.dll
As you can see, it's quite a lot of files. I've been wondering if this the "correct" way of doing this? Is there an alternative way that is considered "best-practice" in this case?
There's nothing wrong with this approach, and it's probably the quickest way to get your application up and running. Your application needs these libraries, so putting them in the same folder allows it to find them.
There are of course always alternatives!
Static linking
To avoid having a bunch of dlls that have to exist with your application, you could use static linking. You link the .lib files at link-time rather than linking to the .dll files at run-time. Makes your .exe larger, but means you may be able to distribute a single file.
Placing Dlls in a different folder
The dlls do not have to be in the same folder as the .exe, though that normally makes the most sense. Windows will search several folders when looking for a .dll at run-time, so you could put the dlls in the current directory, a system directory (definitely not recommended), or another directory in your PATH environment variable. Actually none of those locations are recommended! Putting them in the same folder as the .exe is the safest, because generally you have control of that folder.
The specific rules for how Windows searches for a .dll are outlined here: http://msdn.microsoft.com/en-ca/library/windows/desktop/ms682586(v=vs.85).aspx
Custom Build Step
I don't like manually putting files in my debug or release folders. I like to think of the debug folder as something I can blow away and rebuild at any time, and I like to have a one-step build process that puts everything where it needs to be so I can easily build on any machine. So I will usually create a custom build step that copies the required .dlls from a "source" folder (in source control) into my output folder.
What I am trying to do is exactly like the instructions on this website:
http://www.cprogramming.com/tutorial/sdl/setup.html
The only problem is that I didn't download the version of Code Blocks that comes with the mingw32 compiler. I got the latest release from http://www.equation.com/servlet/equation.cmd?fa=fortran and installed it in 'C:\gcc'. So, the folders that it is asking me to move files into don't exist.
The article asked me to download this file:
SDL-devel-1.2.15-mingw32.tar
Then in that file move the 'include\SDL' folder into the 'C:\Program Files\CodeBlocks\include'. (I don't have a CodeBlocks\include folder)
It then asked me to move the 'SDL.dll' to 'C:\Windows' which I was able to do.
Finally it wanted me to copy the contents of the 'lib' folder into the 'CodeBlocks\lib' folder. (Another folder I don't have because I installed my compiler separately from the Code Blocks install)
Since I installed my compiler at 'C:\gcc' I tried to add the files into the 'C:\gcc\include' and 'C:\gcc\lib' files, but that didn't work.
I am not very familiar with the process of using 3rd party libraries. I usually use Java where you can just stick the .jar file in with your code. Do I need the .dll, include, and lib files. Where do I actually need to put them? I would also appreciate knowing why as well?