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?
Related
Below is a picture I grabbed off google, and it is actually linked back to a previous Stackoverflow question.
So, on the left (project explorer view) we see an Includes and src directory. I believe the Includes really is just paths to where header files may reside in the file system.
So now for my question, should header files I have made say "xyz.h" reside in the src folder in an Eclipse project?
Currently I put them somewhere in the file system on my Linux machine and then path to them (so they show up in the "Includes" for the project), this allows me to edit them in the eclipse editor and so forth, but I believe they are not actually a part of the "Eclipse project".
Not sure there is a right and wrong answer, just looking for what others few as the "best" way.
Generally the header files that you create should be in your project.
The main purpose of the "Includes" mechanism is finding the headers of third-party libraries that your project may use.
You can also use it to specify the location of includes inside your project. For example, you might have an include folder inside your project, put all (or some) of your headers there, and configure that as an include path. Eclipse allows you to configure include paths relative to the project, by choosing "Project Path" when adding the include in the project's Paths and Symbols preference page.
As your projects get large, you may eventually want to split them up into several projects, such as an application and supporting libraries. In a case like that, the application's project would have include paths pointing to the headers in the library projects.
I'd like to include some folders of static files shared between many projects and solutions.
These files could be images, script libraries or css that are shared between many projects.
I do not want to copy each time the folder inside the project structure but reference it just as we can link files between projects in the same solution so if any file changes in the referenced folder all the projects that link to it will have an updated version.
I know I can put it in a shared dll and embed resouces in it but I'd like to be able to choose witch folder to include.
Is this possible with Vs2010 or Vs11?
Sure, its possible, and not even that hard. Put the files in a well-known location in your hard drive, then add them to each project as a link. See the second section in the following article:
http://msdn.microsoft.com/en-us/library/9f4t9t92.aspx
If you use source control, I would strongly encourage you to have at least one separate folder per solution file, and nest the folder under your solution root somewhere. TFS, in particular, gets antsy if your solution file includes locations that are outside the current workspace. (It will work but you may get strange warnings or errors, particularly if someone else tries to get the solution for the first time.)
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.
what is copy items into destination group's folder (if needed)
is this a good option? If I dont choose it will it just make a reference to my files?
Also if I have two images with the same name like /images/home.gif, /public/home.gif
but they are in different groups how does the compile know which image to use? is this even possible?
I'll have a crack at this :-)
1 & 2 - Used when adding files to a project. If selected, the file you are adding is copied into the projects directory from wherever it originally was. Note it is copied. If not selected, the project can still use it, it just has a reference to the original source file. Which means that if something happens to the original file, the project will not longer have a copy it can use. Personally for files such as images I copy them into the project so they stay with the project. For other things such as external apis, I don't because I don't want multiple copies everywhere.
3 - If you have two images with the same name you won't be able to copy them in without renaming one. XCode may do this for you, I've never tried. I'd suggest renaming one so you control it's name.
4 - Don't get confused by groups. They are logical groupings of files within XCode and do not refer to the underlying file system. Having said that you can actually assign a directory to a group so if you really wanted to you can match the two. I tend to do it a little. In my projects I generally have a src and test directory. I setup two groups and assign them to refer to these directories. Then when I create a new source code file I can create it in the src or test group and it will be created in the sub-directory instead of the project root directory. Often below src and test I will use other groups, but they do not map to any sub directories. The result is that the root directory of the project is free of source code files and the source code also has source and test code separated.
I recently asked about the wisdom of using multiple Xcode projects to separate project components. I have decided to follow this route in my next project.
I attempted to add another project to a master Xcode project by dragging and dropping it into the sidebar. However, when I #import any of the classes that are defined in the added project I am informed that those classes cannot be found.
What do I need to do in order to be able to refer to the classes in other projects in a master project? I was surprised that I found virtually no information on how to do this on the web.
Project -> Edit Project Settings
Use Header Search Paths
This is a list of paths to folders to be searched by the compiler for included or imported user header files (those headers listed in quotes) when compiling C, Objective-C, C++, or Objective-C++. Paths are delimited by whitespace, so any paths with spaces in them need to be properly quoted. See the description of the Always Search User Paths build setting for more details on how this setting is used. If the compiler doesn't support the concept of user headers, then the search paths are prepended to the any existing header search paths defined in Header Search Paths. [USER_HEADER_SEARCH_PATHS, -iquote]