This question have been asked numerous times, but I have not managed to get an answer that I am happy with. Probably because the most answers is of "how do I do this?" type and also get "this way you do this" answers.
The problem I have is that I need to use absolute paths when I want to reference to images in Xcode (version 6.0.1). I am quite sure that I could place the images in my working directory which is something like:
/Users/patrikek/Library/Developer/Xcode/DerivedData/ChessGame-
ftpbqerfsenxxbfvneyzfwdmtwjk/Build/Products/Debug
Then add the file to some Xcode group in project navigator (eg. images/myImg.png) and I would be able to reference the file as myImg.png (since I have not foldered the image inside my working directory). I am also quite sure that the project navigator stuff would not b required for this to work.
And after this introduction comes the questions:
1) Is it necessary to place all images and other resources in the current working directory? Also, if not what is the best way to store folders in a program and is it necessary to name the folder containing images to Resources?
2) Is it possible to arrange files using the project navigator? What I am after is to use the project navigator only and let Xcode worry about the details of copying files and so. It seems somehow unnecessary to have a project navigator, when the physical files are not packaged in the same way. It does also seem error prone to update the project navigator and the physical hierarchy independently of each other.
An example:
I create a folder images in the Project navigator, inside that folder am I placing a reference to the image using the usual way in the project navigator. Is it now possible to make Xcode arrange so that I can do a call images/myImg.png when I want to load the image in some function (without me doing anything, since if I move many images to my working directory I may forget one and I may also spell images wrong by mistake if I create another folder in my working space). Also what have happened inside Xcode when this action was done?
Since I am not at all familiar with Xcode yet I may have got something wrong here, but the core of this problem is to find out where the files physical location must/should be and if there is some way to let Xcode do this by using the project navigator.
BR Patrik
Xcode does not manage images the way you have presumed that it does. Take a look at the 2013 WWDC "What's New in Xcode" video to see how Xcode 5 and Xcode 6 organize and manage images for any given project. When you have configured the asset catalogues for your project correctly, it wouldn't matter where the original images live on disk. As long as you have dragged the right assets into the right catalogues, your projects will work. The good news is that you only need to configure images once and change only the ones that change once done. For details, see this wwdc video: http://devstreaming.apple.com/videos/wwdc/2013/400xex2xbskwa5bkxr17zihju9uf/400/ref.mov
Once an image is configured in the asset catalogue, you can refer to it with or without it's file extension. For example, you can refer to "example.png" as "example" in your code. Hence, "myImg.png" can be "myImg" or "myImg.png" in code. No need to worry about which subdirectory contains it.
Now if your question has to do with runtime assets, again your development system directory structure would not matter. If that is the case, then you might have to re-ask your question. I would be glad to help you there as well--if that's what you want to know.
This question have been asked numerous times, but I have not managed to get an answer that I am happy with. Probably because the most answers is of "how do I do this?" type and also get "this way you do this" answers.
The problem I have is that I need to use absolute paths when I want to reference to images in Xcode (version 6.0.1). I am quite sure that I could place the images in my working directory which is something like:
/Users/patrikek/Library/Developer/Xcode/DerivedData/ChessGame-
ftpbqerfsenxxbfvneyzfwdmtwjk/Build/Products/Debug
Then add the file to some Xcode group in project navigator (eg. images/myImg.png) and I would be able to reference the file as myImg.png (since I have not foldered the image inside my working directory). I am also quite sure that the project navigator stuff would not b required for this to work.
And after this introduction comes the questions:
1) Is it necessary to place all images and other resources in the current working directory? Also, if not what is the best way to store folders in a program and is it necessary to name the folder containing images to Resources?
2) Is it possible to arrange files using the project navigator? What I am after is to use the project navigator only and let Xcode worry about the details of copying files and so. It seems somehow unnecessary to have a project navigator, when the physical files are not packaged in the same way. It does also seem error prone to update the project navigator and the physical hierarchy independently of each other.
An example:
I create a folder images in the Project navigator, inside that folder am I placing a reference to the image using the usual way in the project navigator. Is it now possible to make Xcode arrange so that I can do a call images/myImg.png when I want to load the image in some function (without me doing anything, since if I move many images to my working directory I may forget one and I may also spell images wrong by mistake if I create another folder in my working space). Also what have happened inside Xcode when this action was done?
Since I am not at all familiar with Xcode yet I may have got something wrong here, but the core of this problem is to find out where the files physical location must/should be and if there is some way to let Xcode do this by using the project navigator.
BR Patrik
Xcode does not manage images the way you have presumed that it does. Take a look at the 2013 WWDC "What's New in Xcode" video to see how Xcode 5 and Xcode 6 organize and manage images for any given project. When you have configured the asset catalogues for your project correctly, it wouldn't matter where the original images live on disk. As long as you have dragged the right assets into the right catalogues, your projects will work. The good news is that you only need to configure images once and change only the ones that change once done. For details, see this wwdc video: http://devstreaming.apple.com/videos/wwdc/2013/400xex2xbskwa5bkxr17zihju9uf/400/ref.mov
Once an image is configured in the asset catalogue, you can refer to it with or without it's file extension. For example, you can refer to "example.png" as "example" in your code. Hence, "myImg.png" can be "myImg" or "myImg.png" in code. No need to worry about which subdirectory contains it.
Now if your question has to do with runtime assets, again your development system directory structure would not matter. If that is the case, then you might have to re-ask your question. I would be glad to help you there as well--if that's what you want to know.
I am having some troubles using eclipse to navigate a massive project. The problem I am attempting to facilitate is searching for where functions are defined, where classes are defined, and following other references throughout the code.
I was previously using grep to search everything, and that was no a very good solution as it took about 2 minutes for every search.
Is there a way to add all files to my Eclipse index?
the file 'soc-core.c' is currently not part of the index.
Here's a screenshot to illustrate. I believe I have selected the appropriate options. Thanks so much!
If you have large files in terms of LOC, you may be taken into scalable mode by eclipse where indexing didn't work for me. So. I changed the scalability settings to 50,000 lines. Now indexing is working large files too (<50k)
It sounds like you might be hitting a limit that prevents indexing from finishing. Here are some things to try.
Increase the memory available to eclipse. In your eclipse.ini file, set the -Xms and -Xmx values to bigger numbers. I'm using -Xms512m -Xmx2048m but you may need even bigger.
Increase the "Cache limits" fields at the bottom of the Indexer preference page.
Start eclipse and let it sit for a while. It should show you "C/C++ Indexer: (X%) progress bar in the lower right corner. Give it time to get to 100%.
You might try rebuilding the index. Menu->Project->C/C++ ndex->Rebuild.
In your project settings, you might need to add directories to C/C++ General->Paths and Symbols->Includes
Get a newer version of eclipse-cpp. I had a version a long while back that never seemed to finish indexing--it would get stuck. I'm now using eclipse-cpp-kepler-R and it works great.
I have a simple build definition which I want to use to build just one project, and every time I choose to run this build, I want to get latest from the branch/directories that pertain only to the project in question. How do I do that? The call to "Get Workspace" gets everything from source control, and I do not want to (or need to, for that matter) get latest from everything for various reasons.
I hope I am not asking for much.
Thanks in advance.
Check the workspace mapping in the build definition. The build only gets the items that you have specified over there. If you want to exclude some folders within the path that you are mapping, you can choose to cloak some folders.
You can adjust your ItemsToBuild in Process Tab in Required section
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
When creating a new C++ header/source file, what information do you add to the top? For example, do you add the date, your name, a description of the file, etc.? Do you use a structured format for this information?
e.g.
// Foo.cpp - Implementation of the Foo class
// Date: 2008-25-11
// Created by: John Smith
One team I know embeds CVS commit messages to the foot of each file, but I'm not sure I want to go this far...
Information about who created a file and when and who edited it and when is all in source control. If your team has good practices around check-in comments, then you'll know the reasons for each change too. No need for comments for that stuff.
I think it's 100% legit - wise, even - to put a comment block, as long as is necessary, explaining the purpose of the class/module. When the next person goes to change it, they'll have a better idea of the overall vision and whether this file is the appropriate place for their change.
Some shops put copyright notices and other legal folderol in source file comments. This strikes me as just silly - if your (non-OSS) source code has made it onto someone else's servers without your knowledge or permission, a copyright notice is probably not going to deter them from doing anything with it. IANAL, YMMV.
Don't. Most of the stuff can be retrieved from the versioning system when needed so it's redundant to add. That would leave you with the description of the content of the file but that's part of the class documentation most of the time (or at least the documentation of the specific type).
I don't do any of those, but then again, I don't like the cruft.
We're required to put copyright information at the top of each file. I think dates, authors, and the name of the file is a waste of time.
We also have our source control system append check-in comments at the bottom of each file. I initially hated the change log, but over time I learned to like it. It really helps when merging changes.
I include the file name, a brief description of the file's purpose, and a $Id$ tag for CVS or Subversion purposes. File creator and date of creation can be found by checking the repository, so it's not needed.
File name is included because depending on what you're using to edit the file, that might not be entirely apparent when you're editing it. The description can be used to determine if a bit of code belongs in the file, or if it should be moved to another. And of course, $Id$ gives you last change time, and last editor.
Embedding check-in messages is only useful when the message is useful, and only if the file is updated once and a while. Including every message will simply bloat the file to the point where there's more comments describing changes than there is actual code. Best to leave that to the repository as well; often it's only a short command line to get the file's check-in log.
If you're stuck with a revision control system that can't keep history for moves and copies, in that case just reference the original file and its version number. Of course, if you're using a system that was created sometime in this century and not the last, that shouldn't be an issue.
I used to like putting version control keywords in the header of file. But recovered from that affliction. :) For two reasons:
Nobody put comments in that are of any use. You always wind up looking at the diffs reported by the version control system.
It creates a nightmare in trying to diff large filesets because the keywords create differences that are the only difference in the file.
Originally answered here, but since deleted: 134249
I would only put two things:
licensing/copyright information
comments required by documentation-generating tools (i.e., the comments have to be in the header to work - otherwise, they should go in the definition files)
Anything else is unnecessary fluff that won't be maintained, and will eventually become worse than nothing at all.
At the time I worked for a large defense company, and we had draconian coding standards. If you followed them to the letter (and most people don't), most of your headers would be composed mostly of that meaningless fluff. Doubly worse is that the exact same fluff is required to be placed in source files as well, which means two copies of the fluff gets out of date and becomes misleading.
I don't embed the date because it's redundant. If someone wants to know the date a file was created don't trust the author, trust your source control system. It should be the defintive answer for the date of creation.
I'm definately not against embedding check in messages though. Those are pretty useful.
We use our RCS to automatically stamp the following on the file:
Copyright,
RCS file name,
Date modified,
Author of last change,
RCS revision number
I think this is very convenient. I really like having the file name automatically populated in each file, because it makes searching the solution for files very quick.
This is what i normaly put at the top of files:
///////////// Copyright © 2008 DesuraNET. All rights reserved. /////////////
//
// Project : [project name]
// File : [file name]
// Description :
// [TODO: Write the purpose of ... ]
//
// Created On: 11/12/2008 2:24:07 PM
// Created By: [name] <mailto:[email]>
////////////////////////////////////////////////////////////////////////////
and i set up a macro in vis to do add it in and fill in default info when i make a new file
If you're using CVS, check out it's keyword substitutions. They will help automate embedding that information.
Personally I stick this at the top of all of my source files:
// $Id$
Other informative comments I embed to be parsed with doxygen, if they relate to something specific (the file, the class, a type, etc).
i generally only add any "comment info" when...
i don't think i'll remember or its not obvious what something is doing
or
when i release the source code and i actually want others to be able to use/learn from it.
I usually include a description of the purpose of the code found in that file. Everything else seems to be handled elsewhere: dates and comments in source control, etc.
Everyone is saying that your source control will have the date and programmer info, but that isn't always true. I worked in a shop that used Source Safe, and it was fine until someone decided to move a file to a different location. At that point, it essentially became a new file according to SS, and no previous history existed.
Perhaps because of that, the programmer name and date were automatically added to the comment section at the top of the file. When there got to be more than about 10 entries, we'd strip out all of the middle ones, leaving only the original date and author, and the current information.
A copyright statement for my client ;-)
We use MSVC & VSS and have a plugin that adds any comment you specifiy at check-in to the file that's being checked in as a comment. It's very convinient to look at the top of the CPP file to find out the bug-tracking ticket number that a change was made for.
I use Subversion.
Here's what I like to put near to the top.
$Id$
$HeadURL$
That substitutes the revision, last editor, and then the location of the file in the repository. Although I always work from working copies, this lets me print/email a file and look at it later to know exactly where it came from. $HeadURL$ especially is nice because it tells what project and branch the file is in and how to get to it (nice with larger nested subpackages and the like).
Agreed on the uselessness of big manual comment blocks — although docstrings/Javadocs are recommended — and on automatically appending the commit log.
It sounds like some of you are using terrible VCSes, if you are getting diffs or merge conflicts generated by the keywords themselves. Subversion handles it well.