Rubymine is taking over an hour to index a new project because it is including every Ruby file found on my computer as external libraries.
I do not want any of these files included in my project, but I cannot figure out how to exclude them. If I right click on them, I have the option to delete them, but it actually deletes the file instead of just removing it from the library and I don't want that. I have looked all through the settings and seen nothing about setting the external libraries. Anyone have any ideas?
Related
I am creating a library for Mac using XCode5 which is using some code (c++) that is being developed and maintained by other developer and is at a different path than my library project.
e.g. my project is at /svntrunk/../../mylibraryproject/
The code I want to compile(use) in my library is at
/svntrunk/../../../utils/networkutils/src/source files here
I have tried following approaches
Refer the source files into my project but don't copy them into my project, that way when the other developer updates his code that is automatically reflected since I am pointing to his location. But in this case the linker fails to find the symbols from networkutils code.
Here while adding the file to the project I don't select 'Copy items ..' option
Second approach I took is to select 'Copy items..' option while adding the source files from networkutils to my project. This way the files is copied to my project and the compiler is able to find the symbols. But now if the other developer updates networkutils code I have to manually copy the updated code files which doesn't seem to be right thing to do.
It seems that to move forward I will have to go with option 2. Please let me know if there is a better way to approach this problem.
Thanks
Dev
If he's developing using Xcode as well and has a project, you could link to the project, build that as a lib and include it in the build dependencies in your project.
I do this for Cocos2d.
Failing that, I would pursue option 1 and try to figure out why it's not finding the symbols. Are you sure you have the correct headers included? One reason the compiler fails to find symbols is that you're using functions whose headers are not included.
Extra info here:
https://stackoverflow.com/a/17415609/290072
OK, here's my issue :
I'm using Xcode 4.6 under Lion
In my current project I've added several "real" folders (either with sources or with resources) which Xcode represents as "Groups"
However, whenever I add another file in one of my already-imported folders, the file doesn't show up (but instead I have to manually drag each new file to its appropriate location).
Well, given that my project is comprised of hundreds of different files, and that files are being added constantly, this seems like an overkill.
I realize this may have to do with Xcode's Group-centric approach, but it still bothers me.
So, is there any workaround? Any ideas?
As for many IDE, it won't scan changes of new files in included folder, to prevent accidental add of extra codes that will break the compile process. If you really want to do so, write a script to add all files in the folder and run it at pre-compile stage, i.e. in Xcode, "External Target"
See: https://stackoverflow.com/a/976459/188331
Codeblocks cannot find definitions or declarations of some functions in my project.
Question: Is there a way to force a re-scan of the source tree?
I believe that all of the relevant files are included into the project.
(Just checked: it cannot find by name a struct declared in an opened file.)
First, let me give a couple of ways to help C::B find your declarations/definitions.
Although somewhat obvious, you should make sure the function is in a file that is either:
1) part of the project itself (i.e. it should be shown in the projects->workspace window). If you intended it to be part of the project but it isn't there, then go to project->add files and add the file.
2) If you don't want/need the file to be part of the project but you still want to access the declarations/definitions, you need to let the project manager know where to find the file. You can do this in project->build options and set the search directories. Be careful when setting the search directories...you can set it for the whole project or build target (debug or executable).
Note: one common problem occurs when you have multiple projects open in C::B. Even though all your projects are "open", there is only one that is "activated". So, just because you have a file open, it doesn't mean the file is part of the activated project. You can do search-->open files" which will find code in a file if it's open but not in the current active project.
The only way to "re-scan", is to rebuild your project after making changes in the source code or project settings. You may have to restart C::B. If you still can't find the declaration/definition after doing the above, I would suggest you make a sample program and see if it will find the declaration/definition. If it does, then you can check the settings between your project and the sample project. In the worst case, you can copy your code from your project to the sample project. If that doesn't work, you can reinstall C::B and try again. Not fun but sometimes it works.
You can try, rebuilding the project, but make sure at least one other file includes the header for the structure or make sure the header and source file are included in the project.
I have a couple of different solutions, in which some projects may depend on output from projects in other solutions. To manage this, I've been copying dll files from the /bin/ folder in each project to a shared library location after build, and then copy/reference them from there to the dependent project.
However, as the library solution gets larger, this tends to become unmaintainable. Too much of my time is being spent traversing solution directories in Windows Explorer looking for /bin/ folders, and trying to figure out which one, or which ones, of the dll files from each one I need.
Is there any way to give Visual Studio a hint that I want all projects in a solution to have the same output directory? For example, a /bin/ folder directly under the solution folder, where all projects put their output.
If possible, I'd like to achieve this without hard-coded post-build events that copy the files, since that will fail if a project output changes file name, or adds another file. I'd rather like to change the location of the actual output directory - the location of $(OutDir), if you will.
I know you said you don't want to use post build events, but your reason as to why not intrigued me. It sounds like you might be hard coding the name of the .dll in your post build event. That can easily be avoided.
xcopy "$(TargetDir)*" "c:\common\" /Y
The * would just cause everything in your bin/Debug/ folder to get copied to your common folder. You could also just copy dlls if you want. Or, if you use $(TargetPath), you'll copy just the 1 dll that is the result of the project, and not any other related dependencies.
UPDATE
The way we do it is each projects entire bin folder is copied to a subfolder. Suppose you have 2 projects, WebUtil and HtmlParser, where WebUtil depends on HtmlParser. For both projects, use xcopy "$(TargetDir)*" "c:\common\$(ProjectName)" /Y. This will create c:\common\WebUtil\ and c:\common\HtmlParser. In WebUtil, add a reference to c:\common\HtmlParser\HtmlParser.dll. There will now be 2 copies of HtmlParser.dll in c:\common.
c:\common\HtmlParser\HtmlParser.dll // the most recent build.
c:\common\WebUtil\HtmlParser // what was the most recent build when WebUtil was built
This has all kinds of advantages. If you change the API of HtmlParser, WebUtil will continue to work, since it will have the older HtmlParser.dll until you try to rebuild WebUtil (at which point you'll get build errors because of the changed API).
Now, if a 3rd project got in the mix that depended on WebUtil, and you're using some part of WebUtil that exposes classes in HtmlParser, then you'll need to add a reference to both projects from your new project. When you add a reference to HtmlParser.dll, use the one in c:\common\WebUtil. You do this because you're only including it as a necessary requirement of WebUtil. Now you'll always have the version of HtmlParser.dll that matches your current version of WebUtil.dll.
I hope that makes sense. It can definitely be a tricky thing to manage. Just wait till you have to start pulling down all your dependencies using svn:externals =P
You can set the output directory in each project properties.
Right click on the project, select Properties
For C#, it is one of the Build property page, under Output, Output directory.
In VB.Net projects, it is on the Compile tab, in the textbox at the top.
I'm new to XCode and I find the file management a huge pain. In most IDEs, you can simply have the project source tree reference a directory structure on disk. This makes it easy to add new files to your project - you simply put them on disk, and they will get compiled automatically.
With XCode, it appears I have to both create the file and separately add it to the project (or be forced to manipulate the filesystem through the UI). But this means that sharing the .xcodeproj through source control is fraught with problems - often, we'll get merge conflicts on the xcodeproj file - and when we don't, we often get linker errors, because during the merge some of the files that were listed in the project get excised. So I have to go and re-add them to the project file until I can get it to compile, and then re-check in the project file.
I'm sure I must be missing something here. I tried using 'reference folders' but the code in them doesn't seem to get compiled. It seems insane to build an IDE that forces everyone to modify a single shared file whenever adding or removing files to a project.
Other answers notwithstanding, this is absolutely a departure from other IDEs, and a major nuisance. There's no good solution I know of.
The one trick I use a lot to make it a little more bearable — especially with resource directories with lots of files in them — is:
select a directory in the project tree,
hit the delete key,
choose "Remove References Only", then
drag the directory into the project to re-add it.
This clobbers any manual reordering of files, but it does at least make syncing an O(1) operation, instead of being O(n) in the number of files changed.
I'm intrigued which IDEs you're using that automatically compile everything in a directory, as no IDE I've ever used does that (at least for C++). I think it's pretty standard to have a project file containing a list of all the files. Often you may want to only include certain files for different targets, have per-file compiler settings, etc.
Anyway, given that that's how it does work, you really shouldn't have too many problems from merge conflicts. The best advice would be commit early and often so that you don't get out of step with other people's changes. Merely adding files to the project shouldn't result in a conflict unless they happen to be added at exactly the same point in the project tree. We've been using Xcode in our team for years and we very rarely get conflicts: only if someone has restructured the project.
Fortunately, because the Xcode file format is text, it's generally quite easy to resolve conflicts when they occur, unlike the Bad Old Days of Codewarrior with it's binary format.