I installed the multilib version of mingw-w64 so I could build both 32-bit and 64-bit binaries. Here's a tree representation of the files: http://pastebin.com/r4QUnbwJ. If you only want to view the directories, see this instead: http://pastebin.com/2m6uqt4E. It looks like there are duplicate files in some cases, like in the bin directory. Are they different in any way? Also, I see one directory named "mingw" and another named "x86_64-w64-mingw32". They look about the same in content. Again, what is the difference?
Basically, I just want an explanation of the file layout. I'm not expecting a description of each file, but it would be good if some of the main concepts within mingw-w64 (multilib) were addressed.
In my experience, the /mingw directory can safely be deleted. It is only needed for the strange GCC build system (and can even be empty in some cases).
The x86_64-w64-mingw32/bin directory contains executables called by gcc/g++/gfortran/etc. internally. Don't delete them.
There doesn't seem to be a "standard" directory structure, sometimes the x86_64-w64-mingw32/lib(32) and x86_64-w64-mingw32/include directories contain the same files. Sometimes the same files are even in the root include and lib(32) directories. If you need an expert's answer, feel free to post to the minwgw-64 mailing list, a lot of knowledgeable people reside there.
Related
I just unzipped sublime_text_3_build_3143_x64.tar.bz2 and have a nice copy of the sublime_text_3 directory in my downloads folder.
Where is the right place to put this file in Centos? Maybe somewhere in /user/local/?
Also do I create a link to the executable or set a Path?
Just looking for favorite (best?) practices.
As has been pointed out in the linked article in the question comments, /opt is preferred by some, and in fact according to this answer, /opt is where you would locate "unbundled packages". Of course, it also goes on to say that these sorts of packages should also package the binary in a bin subfolder, which Sublime does not, for what that's worth.
If you want to follow best practices, that's probably where you should place the folder. If nothing else, I would assume that any Linux OS that has a package manager for doing upgrades is going to stay well clear of /opt based on what it's used for, which will make sure that something untoward can't happen.
As to whether you would create a symlink or add that folder to the path, I'm not so sure. My own personal philosophy is that the PATH isn't something that needs to have an entry for every application that I install.
My own recommendation would be to create a symlink somewhere that's already in the path and you're good to go. The linked article mentions putting the link in /usr/bin. The Filesystem Hierarchy Standard says of this path:
This is the primary directory of executable commands on the system.
I would take from this that this is an acceptable path to put the symlink in.
In the end, it doesn't matter to Sublime where the folder is placed, since it determines the location of the shipped packages based on where it's binary is located, and the configuration information is always in a known place.
I have been using git for some time now and I feel I have a good handle on it.
I did however, build my first small program as a distribution (something with ./configure make and make install) and I want to put it up on github but I am not sure how to exactly go about tracking it.
Should I, for instance, initialize git but only track the source code file, manpage, and readme (since the other files generated by autoconf and automake seem a bit superfluous)
Or should I make an entirely different directory and put the source files in there and then manually rebuild everything for version 0.2 when it is time?
Or do something else entirely?
I have tried searching but I cannot come up with any search terms that give me the kind of results I am looking for.
for instance initialize git but only track the source code file, manpage, and readme (since the other files generated by autoconf and automake seem a bit superfluous)
Yes: anything used to build needs to be tracked.
Anything being the result of the build does not need to be tracked.
should I make an entirely different directory
No: in version control, you could make a new tag to mark each version, and release branches from those tags to isolate patches which could be specific to the implementation details of a fixed release.
But you don't create folders (that was the subversion way)
should I make an entirely different directory for sources
Yes, you can (if you have a large set of files for sources)
But see also "Makefiles with source files in different directories"; you don't have just one Makefile.
The traditional way is to have a Makefile in each of the subdirectories (part1, part2, etc.) allowing you to build them independently.
Further, have a Makefile in the root directory of the project which builds everything.
And don't forget to put your object files in a separate folder (not tracked) as well.
See also this question as a concrete example.
In automake's Makefile.am , the sources of a program is listed like
bin_PROGRAMS = os345v1
os345v1_SOURCES = os345.c os345interrupts.c os345semaphores.c
Instead of specifying individual files, How to add all c files in a specific directory and subdirectory ?
it's usually a bad idea to do use wildcards in automake.
for one thing, your automake project might be processed used with a non-GNU make implementation (which might not be able to use GNU-make extensions such as $(wildcard *.c)).
One of the strengts of autotools/automake is that it is agnostic of the target systems and their tool-chains.
More importantly, automake might need to actually know exactly which source files you want to be build.
This is important for instance when you want to make out-of-source-tree builds (e.g. with the source-code on read-only media, and the builds being "somewhere else): this is a common use-case for distributions (e.g. Debian) that allow to easily build multiple flavours (with different configure flags) from the same source in a single run.
And finally, not using wildcards protects your build against stray source code. E.g. having "foo.c" and a backup-file "foo_old.c" (e.g. because you are re-implementing "foo" and want to have check with the old implementation and want your editor to automatically enable syntax-highlighting) lying around in the same folder, might accidentally build both files resulting in multiple-definitions of the same symbols.
See also the automake documentation why automake does not support wildcards
I've defined a CMakeLists.txt file for my project which works correctly.
I use the CMake GUI for generating a Visual Studio Project, and I ask to build the binaries (CMAke cache and other stuff) in the folder Build which is in the same folder where CMakeLists.txt is.
I was able to specify where the executable and the libraries have to be created.
Is there a way to specify also where the Visual Studio Solution file has to be created? I would like to have it in the root directory, but at the same time I don't want to have also all the other files that CMake creates in the Build directory.
CMake creates the Project I defined in CMakeLists.txt but also two other projects: ALL_BUILD and ZERO_CHECK. What's their utility?
I was able to avoid the creation of ZERO_CHECK by using the command set_property(GLOBAL PROPERTY USE_FOLDERS On).
Is there a way for avoiding also the creation of ALL_BUILD?
It seems you only switched to CMake very recently, as exactly those questions also popped into my head when I first started using CMake. Let's address them in the order you posted them:
I use the CMake GUI for generating a Visual Studio Project, and I ask
to build the binaries (CMAke cache and other stuff) in the folder
Build which is in the same folder where CMakeLists.txt is.
Don't. Always do an out-of-source build with CMake. I know, it feels weird when you do it the first time, but trust me: Once you get used to it, you'll never want to go back.
Besides the fact that using source control becomes so much more convenient when code and build files are properly separated, this also allows to build separate distinct build configurations from the same source tree at the same time.
Is there a way to specify also where the Visual Studio Solution file has to be created?
You really shouldn't care.
I see why you do feel that you need full control over how the solution and project files get created, but you really don't. Simply specify the target for the solution as the origin of your out-of-source build and forget about all the other files that are generated. You don't need to worry, and you don't want to worry - this is exactly the kind of stuff that CMake is supposed to take care of for you.
Ask yourself: What would you gain if you could handpick the location of every project file? Nothing, because chances are, you will never touch them anyways. CMake is your sole master now...
CMake creates the Project I defined in CMakeLists.txt but also two
other projects: ALL_BUILD and ZERO_CHECK. What's their utility? I was
able to avoid the creation of ZERO_CHECK by using the command
set_property(GLOBAL PROPERTY USE_FOLDERS On). Is there a way for
avoiding also the creation of ALL_BUILD?
Again, you really shouldn't care. CMake defines a couple of dummy projects which are very useful for certain internal voodoo that you don't want to worry about. They look weird at first, but you'll get used to their sight faster than you think. Just don't try to throw them out, as it won't work properly.
If their sight really annoys you that much, consider moving them to a folder inside the solution so that you don't have to look at them all the time.
Bottom line: CMake feels different than a handcrafted VS solution in a couple of ways. This takes some getting used to, but is ultimately a much less painful experience than one might fear.
You don't always have a choice about what your environment requires. Visual Studio's GitHub integration requires that the solution file exists in source control and is at the root of the source tree. It's a documented limitation.
The best I was able to come up with is adding this bit to CMakeList.txt:
# The solution file isn't generated until after this script finishes,
# which means that:
# - it might not exist (if this is the first run)
# - you need to run cmake twice to ensure any new solution was copied
set(sln_binpath ${CMAKE_CURRENT_BINARY_DIR}/${PROJECT_NAME}.sln)
if(EXISTS ${sln_binpath})
# Load solution file from bin-dir and change the relative references to
# project files so that the in memory copy is as if it had been built in
# the source dir.
file(RELATIVE_PATH prefix
${CMAKE_CURRENT_SOURCE_DIR}
${CMAKE_CURRENT_BINARY_DIR})
file(READ ${sln_binpath} sln_content)
string(REGEX REPLACE
"\"([^\"]+).vcxproj\""
"\"${prefix}/\\1.vcxproj\""
sln_content
"${sln_content}")
# Compare the updated contents with the existing source path sln, if it
# exists and is the same we don't want to disturb VS by touching it.
set(sln_srcpath ${CMAKE_CURRENT_SOURCE_DIR}/${PROJECT_NAME}.sln)
set(old_content "")
if(EXISTS ${sln_srcpath})
file(READ ${sln_srcpath} old_content)
endif()
if(NOT old_content STREQUAL sln_content)
file(WRITE ${sln_srcpath} ${sln_content})
endif()
endif()
What would be helpful is if cmake had a way to run post generation scripts, but I couldn't find one.
Other ideas that didn't work out:
wrap cmake inside a script that does the same thing, but:
telling users to run a seperate script isn't simpler than saying to run cmake twice. Especially since needing to run cmake twice isn't a foreign concept.
put it in a pre-build step, but
building is common and changing the build is rare
changing the solution from builds inside the IDE makes it do... things
use add_subdirectory because that's suppose to finish first
it appeared to make the vcxproj's immediately, but not the sln until later, but I didn't try as hard because this adds a bunch of additional clutter I didn't want - so maybe this can be made to work
I'm developing application for GNU/Linux using gcc 4 and cmake to manage compilation process. I found that is has no problems when there are two files with the same name but in other directory and namespace like this:
.
|-- gfx
| |-- Object.cpp
| `-- Object.h
`-- logic
|-- Object.cpp
`-- Object.h
First Object class is in Gfx namespace and second in Logic namespace.
Then I've tried to compile this project using Visual C++ 2008 Express Edition. Linker threw several errors about non-existing implementation of Gfx::Object class. After few checks I found out that:
Visual C++ is tracking two of Object.cpp files
When change occurs in first or second file the recompilation of Object unit is queued
It always recompile only the second Object.cpp regardless of which file was actually modified
I also found out that Visual C++ don't allow to create two classes with same name.
Is there a solution for this? I don't really want to refactor quite big part of code.
Both Object.cpp files will be compiled to Object.obj. Into the same directory. In other words, the last one that is compiled will overwrite the Object.obj of the first one. Yes, the linker isn't going to be thrilled by that, you'll get multiply defined symbols since it links the same Object.obj file twice.
The fix is easy, right-click one of the Object.cpp files, Properties, C/C++, Output Files. Change the Object File Name from $(IntDir)\ to, say, $(IntDir)\$(InputName)2.obj
The problem is that by default VC++2008 places all the object files into a single output folder, so the existence of the first object.obj file satisfies the dependency for the second so it is not compiled; and even if it were, it would overwrite the first one.
What you need to be able to do is make the intermediate directory setting dependent in the file being compiled. However I have tried setting it to $(InputDir) and various other combinations, but could not succeed in achieving a configuration that works, although it may be possible. The available macros are documented here.
Failing that you could use a "makefile" project, and manage the build with make, nmake, or cmake or whatever, since there is nothing fundamentally wrong with what you are doing (even if it is ill-advised), it is just that it is not easily supported by the IDE.
This has already been answered, but I also want to add Visual Studio 2010 will automatically put the two .obj files into different directories if there is a conflict, based on my experience with Beta 2.
EDIT: Uh oh, this is wrong! The real answer is that CMake was automatically doing this for me.
The accepted solution is not optimal because it does not scale.
In Visual Studio 2010, I set
Properties -> C/C++ -> Output Files -> Output File Name
to
V:\%(Directory)$(PlatformName)_$(ConfigurationName)_%(Filename).obj
for OBJ files to end up next to the sources assuming the project lies on drive V (no idea whether there is a macro for it, yet).
Not optimal, either - but at least I can easily fork subsystems of many source files without getting tenosynovitis.
By the way: $(InputDir) refers to the solution/project directory and will cause the same problem in another directory.