I was 'cleaning up' a project and deleted some of the references to libs used with openFrameworks. Certain things weren't being used, or so I mistakenly thought... Panic in my project!
All sorts of errors, of course. But, XCode won't let me undo that sort of action. I've re-added the libs but the errors persist. Can someone explain to me what basic conceptual thing I'm missing?
Errors go like this [edited]:
/Developer/openFrameworks-iPhone/libs/openFrameworks/app/ofAppGlutWindow.cpp:61: error: 'glutInit' was not declared in this scope
/Developer/openFrameworks-iPhone/libs/openFrameworks/app/ofAppGlutWindow.cpp:62: error: 'GLUT_RGB' was not declared in this scope
/Developer/openFrameworks-iPhone/libs/openFrameworks/app/ofAppGlutWindow.cpp:62: error: 'GLUT_DOUBLE' was not declared in this scope
[UPDATE]. Two things to check: (1) Having a valid build of the oF library itself. Open library project, make sure it builds.
(2) Is the oF library (and all the other, dependent libraries such as Poco) being added in the Build Phases > Link Binary With Libraries section? Sometimes when you delete and then re-add a library, it doesn't get included on this list. Re-drag the library files here. That's what ultimately solved this for me.
Have you tried clean build? I got this error once when adding static libraries.
Found it: Had to manually add the appropriate libraries to be included under "Build Phases". Built the clean download of openFrameworks that way; afterward I could add that to projects referencing the library and build them!
Related
I want to create a documentation via sandcastle.
Therefore I need to reference DevExpress which should not be documented.
I added the DevExpress dll's under references and the DevExpress resource folder at the project, too.
I tried several different settings, but can't resolve it.
Now Sandcastle shows this Warning several times:
BuildAssembler : warning : ResolveReferenceLinksComponent: [T:test.DEVEXPRESS] Unknown reference link target 'P:DevExpress.XtraEditors.BaseStyleControl.Appearance'. [G:\test\test\test\Testing\Working\BuildReferenceTopics.proj]
How can I resolve this?
I've been facing the same issue for a while now, and I'm just getting around to researching it.
Sandcastle builds documentation which contains clickable reference links. However some references may not resolve because
they are from external assemblies (dependencies). This will cause a warning in the build output. If you're OK with that then just ignore it because there's no harm. However if you have OCD (like me), then follow the instructions below to suppress the warnings.
Instructions
Create a dummy Sandcastle project.
It does not need to be included in the solution, however I find it helpful during the setup.
Disable the project from being built. (Recommended as the build may fail.)
Add the assemblies mentioned in the ResolveReferenceLinksComponent warning to the Documentation Source.
Try to build it. It may fail with "unresolved assembly" errors. (Perhaps dependencies of your dependencies.)
If the "unresolved assembly" is not reference directly in your project then you can ignore it using the Assembly Binding Redirection plug-in.
Otherwise add the required referenced assembly to Documentation Sources as well.
You can also add it to the project References.
Add the dummy Sandcastle project to the main Documentation project using the Additional Reference Links plug-in.
Make sure to configure the plug-in so that all Link Types are set to None.
Note: When updating dependencies, the dummy Sandcastle project's Documentation Sources and reference also need
to be updated. [TODO]: Find a way for this to be automated. Nuget?
Note: Sandcastle does a partial build of the dummy project to gather Type information (via reflection). The dummy project
does not necessary have to build successfully however it must pass the TransformReflectionInfo phase in order for the plug-in to work.
References
GitHub Issue #67
Documentation Q&A
Additional Reference Links Plug-In
Assembly Binding Redirection Plug-In
IMO this is not quite the solution I was hoping for as it adds another project needlessly, however since I had so many warnings that they were masking real issues. Better of two evils I guess.
I have exactly the same problem as in this question: Eclipse: Using "Open Declaration" ... in a Scala project
However, I'm using the latest Scala IDE in version 3.0.2 (I have downloaded the Eclipse bundle from the site), and I would assume such basic functionality works by now, and apparently it's me who have something misconfigured.
I have created a new Scala project. Then I open some standard library class/trait/whatever, let's say scala.util.parsing.combinator.JavaTokenParsers. The source is neatly displayed, but when I try to show class hierarchy, I get the message: The resource is not on the build path of a Java project.
Also, searching for references etc. won't work.
I guess it is a matter of properly configuring the build path? Or maybe I should somehow attach Scala library sources to my project? But I can see the source, so aren't they attached already?
Here is the snapshot of my project configuration:
UPDATE:
By playing a bit with setting/resetting build path stuff, I managed to get rid of pop-up warning but the class hierarchy comes up empty and when searching for references I get only hits from my own sources, nothing from standard library.
In another workspace I also tried randomly adding and removing scala-library jars and got it work almost, but the type hierarchy comes up only with super-classes, without any sub-classes (which renders it quite useless). Searching for references works ok though.
Funny thing, I cannot make it work in my original workspace...
Gotta love Eclipse.
Your build path is not configured properly.
If you take a look under Scala Library[...] you have scala-library.jar we can only see one top-level package scala. There should be numerous other packages besides that. (Ruled Out)
I would recommend you follow these steps
Right-click project, build-path, Java-build-path, Libraries and make sure that the correct library is referenced there.
If it is the one you need, Try to remove this library and add it again, then clean and re-fresh the project. Also try this step in a fresh workspace.(something must have messed up this workspace )
Lastly. Goto the path D:\Eclipse For Scala\configuration\org.eclipse.osgi\bundles\286\1\.cp\lib and verify the sizes of the jars there. There should be 6 jars there and the size of scala-library jar should be around 6.8M. If size is smaller, consider re-downloading
So, I'm working on a project and can't get my XCode 4 workspace to behave. I have the main application as one project in the workspace. I then add the static library project into the workspace. It seems like everything is working okay. I can import files from the other project. It builds, but when I run it, I get this:
dyld: Symbol not found: _OBJC_CLASS_$_iGBC
Referenced from: /var/mobile/Applications/CD00CC83-28E4-4467-96C0-0D1777E21FDA/GBA4iOS.app/GBA4iOS
Expected in: flat namespace
in /var/mobile/Applications/CD00CC83-28E4-4467-96C0-0D1777E21FDA/GBA4iOS.app/GBA4iOS
And crashes. It appears that although Xcode believes the library has been linked, and it builds and runs, the app doesn't actually have the library. But in the derived data folder, it looks like everything that should be there... is there.
I'm going insane with XCode and all it's nuances in settings. Are there sanity checks I can go through to ensure this is working properly? What else can I do?
Edit:
Project settings are valid, and I've already linked the libraries.
Edit 2:
My workspace is setup so the libraries are also in the workspace:
I have removed the lib.a file from the main project and removed it from the Build Phase section, and added it back numerous times. There is no "copy library into destination folder" option when adding it in this way, so I can't do that.
try clean your build, if it don't work, remove the library in build phase and your project folder. When adding the lib to your project, check "copy item to destination if needed", the add that lib in build phase.
I have Eclipse Platform 3.7.2 and CDT 8.0.2.
When I want to do 'Build All' headers from other workspace projects are not counted as dependencies, and nothing is rebuilt.
I have a hello world application and a static library project.
The static library is set as a reference in Project Properties -> c/c++ general -> Paths and SYmbols -> References tab -> checked 'Active'. That's the only setting I changed.
By the way, It totally beats me why Eclipse has an additional "Project References" top-level item under Project Properties.
Anyway, I tried both the External Builder (which gets selected by default on project creation) and the INternal Builder, also coupled with combinations of the global setting 'Preferences -> c++ -> Build -> Build configurations only when there are Eclipse resource changes........'
Thanks for any thoughts on this.
Update:
This is the console output when building dependent project Proj2 (Proj1 is the lib).
'make all' is called but it merely re-links, it doesn't recompile Main.cpp as it should.
Anyone out there familiar with eclipse-generated makefiles? Thanks again.
**** Build of configuration Debug for project Proj2 ****
make all
Building target: Proj2
Invoking: Cross G++ Linker
g++ -L"/home/user/.eclipse-workspace/Proj1/Debug" -o "Proj2" ./Main.o -lProj1
Finished building target: Proj2
**** Build Finished ****
Edit: This is 1.5 years old already, wanted to add that an Eclipse bug had been filed for this:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=375800
there exists a bug for this issue:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=375800
And a working and neat workaround (The orignal requester knows this already). So I just crosslink to the actual answer :) https://bugs.eclipse.org/bugs/show_bug.cgi?id=375800#c11
All credits to Krzysztof Czaińsk
In your project c or c++ compiler settings add -MT ${OUTPUT_PREFIX}${OUTPUT} after the flags:
${COMMAND} ${FLAGS} -MT ${OUTPUT_PREFIX}${OUTPUT} ${OUTPUT_FLAG} ${OUTPUT_PREFIX}${OUTPUT} ${INPUTS}
This will create the correct .d-files
Addition: The workaround has one side-effect. After a clean make all always runs twice before it says nothing to do. Still better than not compiling after a change ;-)
The safest thing to do is to "Clean" the main project first and then rebuild. Often when I know what files in the main project use the modified header files I just "touch" those files and then rebuild. "Touch"ing for me is just adding a space on a line, typically one of the #include lines at the top of the file. Then that file rebuilds and picks up the modified header. Other files that may use that header won't get rebuilt so this is dangerous. For example, if you changed the signature of a method call and you rebuild this way, only the one file will correctly invoke the new method. Call from other source files will likely cause your program to trap. The advantage of course is rebuild speed. Especially when doing unit testing I know precisely which tests I will run so I just touch the relevant files, rebuild run. At some point for safety I always do a clean/build cycle. usually I wait until I need more coffee.
Just throwing this out there but would you not still need to include the headers from the static library in your client code? In which case I think you would need to add the headers in the includes tab of the project properties for your client. Otherwise I'm not sure how you would actually access the static lib implementation in your client.
As for the two references tabs, I believe the one in C/C++ general can be defined separately for different configurations whilst the more general one is for any configuration.
Update:
I would suggest to use that more general reference tab you remarked on. This should make sure your client refers to other projects no matter what the currently selected configuration of the client or referred to project is.
Another Update:
I just realised you mentioned the only setting you changed was the references one. It's another long shot, but I would also check if the include paths for the static lib are actually showing up in the include tab of the projects settings (it probably is). I understand the correct include path is being used at compile time, but eclipse (possibly) uses this tab to determine include dependencies when deciding to initiate a recompile of the client project. It might be worth checking out the "Source Location" tab too and try adding the header location as a source location.
I'm trying (failing) to setup RestKit, which requires one Xcode project to be referenced inside of another. The RestKit framework file creates an NSRegularExpression and appropriately does a #import <Foundation/Foundation.h>. When I build, Xcode spits out "Unknown type name 'NSRegularExpression'".
I'm thinking there might be a circular reference to Core Foundation because I include it in my project and RestKit includes it in theirs? (Remember, the RestKit project is referenced inside of mine, as per their install instructions.)
Also worth noting: In my project build settings, I have the Header and Library search paths set to inside the RestKit/Build path, again, as per their instructions.
I assume you are building your project for iOS. If you included the RestKit.framework in your project, remove it. The .framework is meant to be used in Mac OS projects, add 'libRestKit.a' instead.
I realized I was making the build settings on the project instead of the target. Making sure I was changing paths and libraries on the target instead of the project alleviated all my woes!