I've noticed that some sources have common and/or include as sub-folders. I am talking about C/C++ sources in particular. What are they supposed to contain?
As long as the folder structure is consistent, either way is fine. If the owner(s) of the source have both common and include folders, there should be an obvious distinction. Hopefully these folders do not include other artifacts that should be somewhere else.
Are you having a particular problem? or looking for a 'best practice'? I usually think of an include folder to have .h/.hpp files whereas an common folder could contain images and other non .h/.hpp shared files.
Related
I have several projects which I document with Sphinx. The contents of index.rst are identical in each of them (I use some substitutions for project name and include another rst file with the list of modules). So I thought I could remove this file from most projects and only keep it in one shared project to which the others can find an absolute path during build.
However, the master_doc config does not let me enter an absolute path, and it even rejects relative paths that go "out of scope of the single project". I even tried adding the shared folder in sys.path, but it still did not help.
I've seen many questions asking the opposite, i.e. using multiple index.rst files in a single project. But that's not my case.
Do you have any ideas on how to get this working?
I have a situation where I am using two libraries which have duplicate header file names. For example timer.h exists in both libraries. I think the normal solution to this would be to explicitly specify the directory in the include like #include <dir1/timer.h> or #include <dir2/timer.h> so that the compiler has a clue as to which I am specifying. However, my problem is that one of the libraries I am using is not in a sub directory of my project. It exists somewhere else at a higher level. That is...
Root
Library1
Projects
ProjectFolder
Library2
This was done so that multiple projects could reference Library1. It seemed like a good idea at the time. However, now that I have the name conflict of Library2 it creates issues. One other important detail is that I often use two different workstations. The absolute location of Library1 on these workstations is not the same, nor is the relative location (with respect to the project folder) the same between the two. What I have been doing to this point is adding both absolute locations to the search path of the preprocessor.
Anyway, I'd appreciate any guidance you might offer.
You are on the right track with "dir1/timer.h" and "dir2/timer.h". But rather than think of it as dir think of it as "project1/timer.h". Now in your makefile you will need to have the location of project1 added to your include search path if it's not in a common location.
You shouldn't have relative paths in either your code (no ../file.h). They should be relative to the base directory of their project (e.g. #include <sys/socket.h> or #include <linux/sched.h>). Then it's up to your makefile to find them (those two examples are in the standard search path so they will work). For your case you can -I<path to project directory> and then #include "other_project/library.h".
I'd prefer including a copy of a specific version of the external library with my project and updating to a newer version as needed (but not actually changing the external library from the project). If you just refer to the current (changing) version that everybody uses, then your project may change behavior without even having its code changed. A release of your project would also have to refer to whatever version of the library you were using at that point in time to be complete.
If you did it that way, the relative paths are always the same (say, "../ExternalLib") if you want to use that approach. Or you can do as dave suggests.
As we all know, the common structure of rubygem assumes presence of lib directory. I noticed, that generally in this directory are two items: gem_name.rb and gem_name/ directory. The gem_name/ directory hold main sources of project. It is heart of application. So, the question is about gem_name.rb file. What does it stand for?
The reason it's structured like that is if you had files other than gem_name.rb in the lib/ directory (say another_file_name.rb), you'd be liable to cause problems if there was a gem with the name another_file_name and someone did require another_file_name - it'd load your file, rather than the other gem's file.
If your code is small enough it can all fit into gem_name.rb, then put it there, otherwise put it into gem_name/other_file_name.rb.
Typically that just requires everything from the gem_name/ directory that's needed. It's used to keep all the requires in a central location and separate from the actual code
I've been recently researching how I can manage source files in a project or multiple projects. I've read that Xcode has a built-in support for using svn, and will support git as well, both of which I found to be very useful.
The one thing I couldn't understand clearly is about Source Trees described in Xcode Project Management Guide. Here is my theory, but as I couldn't really verify this from anywhere (as far as I could tell), I would really like if someone could say what I'm missing, if any.
A Source Tree in Xcode preferences is more like a root of a source tree, which is a folder in my local file system.
I can use any files in any of my Xcode projects, even if the files are not in the project folders, if I can specify the files' location related to one of my source trees.
Now someone has the same project folder that is synchronized with mine. She has all files in the project folder, but the files referenced by a relative location to the source tree may exist out of the project folder.
But she has a source tree, with the same Setting Name to mine, (but absolutely in a different folder in her local file system), and if she has the file in the same relative location, then her Xcode can access the file without a problem.
So is this correct, and we use source trees because it enables us collaborating with files outside the project folder?
And even if the files outside the project folder is referenced by a relative path to the project folder itself (not to a source tree), if these files are all managed by SVN so they exist in the same relative location to the project folder in everyone's environments, then I wouldn't need source trees, right?
I never think I am an expert of Xcode, but it seems your question hasn't been answered for a while, so maybe it's worth commenting what I could say:
What you described is pretty much about it. Think is as an environmental variable of an operating system. Typically in a build system made by Autotools, for example, files are referenced by relative paths, such as $PROJECT_HOME/src/common/error.cpp. It doesn't matter where $PROJECT_HOME is in each user's local file system, as long as files are accessible by their relative paths to the user's $PROJECT_HOME directory.
And yes, you don't need to use source tree if the entire folder hierarchy used for a project is referenced by relative paths to the project home and somehow it is certain that everyone has the same files in the same location (for example, because a version control repository contains every files in a chunk as you said).
However, I think it's the best to keep all files in the project home folder, unless they are used across multiple projects, and therefore your version control repository only contains a single root directory (the project home) for your project. If there are files that are best to be shared by multiple projects, then I would have a separate repository for those files. In this case all of your coworkers must use the same protocol, say, having a source tree with the same setting name and put all project homes retrieved from your version control server directly under the source tree (so files outside a project home can be referenced in relation to the source tree for all programmers).
The most of my answer is kind of rephrasing what you already described, but that's how I use the source trees feature in Xcode myself. Maybe others can tell you more about it.
As I create more applications, my /code/shared/* increases.
this creates a problem: zipping and sending a project is no longer trivial. it looks like my options are:
in Xcode set shared files to use absolute path. Then every time I zip and send, I must also zip and send /code/shared/* and give instructions, and hope the recipient doesn't have anything already at that location.
this is really not practical; it makes the zip file too big
maintain a separate copy of my library files for each project
this is not really acceptable as a modification/improvements would have to be implemented everywhere separately. this makes maintenance unreasonably cumbersome.
some utility to go through every file in the Xcode project, figure out the lowest common folder, and create a zipped file structure that only contains the necessary files, but in their correct relative folder locations, so that the code will still build
(3) is what I'm looking for, but I have a feeling it doesn't as yet exist.
Anyone?
You should rethink your current process. The workflow you're describing in (3) is not normal. This all sounds very complicated and all basically handled with relative ease if you were using source control. (3) just doesn't exist and likely never will.
A properly configured SCM will allow you to manage multiple versions of multiple libraries (packages) and allow you to share projects (in branches) without ever requiring zipping up anything.