That's what we have
1) MacOS X Lion, NetBeans 7.0
2) C++ project with source files located on sshfs mounted volume (using Fuse4X)
3) Some libraries header files alse located on sshfs mounted volume.
When I open some source file Code Assistance displays a lot of errors "Couldn't resolve an include" near all lines with include directive and file path containing uppercase characters
#include "SomeModule.h" // error here
#include <Lib/Header.h> // also error here
#include <otherlib/file.h> // wow, no errors
Of course directories containing these headers are added to include path and if I hold 'cmd' button and hover any of these includes correct include path is displayed, but NetBeans still says he couldn't locate that file.
Besides if I create 2 files: File.h и file.h on sshfs volume and try to include them
#include <sshfs/file.h> // includes file.h
#include <sshfs/File.h> // displays an error
My question is what should I do for NetBeans could see, parse and provide content assistance in projects located on sshfs volume?
Related
I completed the CurrencyConverter example using Xcode 2.5 on Mac OS X Tiger 10.4.11, which I called CurrencyConverter2 since it was my second attempt. Since I've read that GNUstep is compatible with the Mac OS X Tiger version of Cocoa, I wanted to try building this Xcode project in GNUstep, which I am interested in learning.
I was able to install GNUstep on a VM running FreeBSD 12.0. I created a Makefile called GNUmakefile. Here are the contents of GNUmakefile:
include $(GNUSTEP_MAKEFILES)/common.make
APP_NAME = CurrencyConverter2
CurrencyConverter2_OBJC_FILES = main.m ConverterController.m Converter.m
CurrencyConverter2_RESOURCE_FILES = Info.plist English.lproj/MainMenu.nib
include $(GNUSTEP_MAKEFILES)/application.make
When building the program using gmake, it appears that everything was built correctly:
This is gnustep-make 2.7.0. Type 'gmake print-gnustep-make-help' for help.
Running in gnustep-make version 2 strict mode.
Making all for app CurrencyConverter2...
Creating CurrencyConverter2.app/....
gmake[3]: Warning: File 'main.m' has modification time 21869 s in the future
Compiling file main.m ...
Compiling file ConverterController.m ...
Compiling file Converter.m ...
Linking app CurrencyConverter2 ...
gmake[3]: warning: Clock skew detected. Your build may be incomplete.
Creating CurrencyConverter2.app/Resources...
Creating stamp file...
Creating CurrencyConverter2.app/Resources/Info-gnustep.plist...
Creating CurrencyConverter2.app/Resources/CurrencyConverter2.desktop...
Copying resources into the app wrapper...
However, when I try to open CurrencyConverter2.app, the main window does not show up at all.
My hunch is that for some reason my Makefile is not recognizing English.lproj/MainMenu.nib.
I also tried using a tool called buildtool that is able to build Xcode projects using GNUstep, but it complained that it couldn't find English.lproj even though it is in the directory that I ran buildtool.
When converting a Mac app to GNUstep, you need to make a GNUstep-specific Info-plist template that roughly mirrors Info.plist (which is Mac-only).
At build time, the Info-plist template is used to generate two files: Info-gnustep.plist, and the app's .desktop (freedesktop.org desktop entry) file.
Info-gnustep.plist contains Info entries used at loadtime/runtime, such as the name of the principal class, the main-menu nibfile to load, etc.
The app's .desktop file contains Info entries used for registering the app with the desktop-environment/file-browser, such as the app's desktop-menu category, the executable path, supported MIME types, etc. (Note: 'make install' currently doesn't register a GNUstep app with the desktop environment; In order for an installed GNUStep app to appear in the desktop menus, its .desktop file - found in its Resources folder - must be manually registered using the 'desktop-file-install' command-line tool.)
The Info-plist template should be named, "{APP_NAME}Info.plist", and can contain a standard XML-format plist, or a simple text-list format:
{
{KEY1} = {VALUE1};
{KEY2} = {VALUE2};
...
}
For CurrencyConverter2, create a textfile named "CurrencyConverter2Info.plist" in the same directory as the Makefile, with the contents:
{
ApplicationName = CurrencyConverter2;
FreeDesktopCategories = ("Utility", "X-GNUstep");
NSExecutable = "CurrencyConverter2";
NSMainNibFile = "MainMenu.nib";
NSPrincipalClass = NSApplication;
NSRole = Application;
}
GNUstep-make will automatically find CurrencyConverter2Info.plist, so it doesn't need an entry in the Makefile.
Unrelated to the Info-plist template issue, you can also make these changes to your Makefile:
Info.plist is Mac-only, so it can be removed from
CurrencyConverter2_RESOURCE_FILES
MainMenu.nib can be specified as a localized resource (so it no longer needs English.lproj in its pathname) by removing it from CurrencyConverter2_RESOURCE_FILES and adding these two lines to your Makefile:
CurrencyConverter2_LOCALIZED_RESOURCE_FILES = MainMenu.nib
CurrencyConverter2_LANGUAGES = English
I studied the HIDL using Nfc code in AOSP .
As i know, when INfc.hal is compiled, INfc.h is autogenerated like following picture.
In NxpService.cpp, there is code like following
#include <android/hardware/nfc/1.1/INfc.h>
But, I couldn't find that path.
where is the real path of android/hardware/nfc/1.1/INfc.h?
In addition, I became curious how gcc compile works in NxpService.cpp that uses INfc.h.
Could you explain how gcc compiler can find INfc.h and work without compile error?
INfc.hal
Path: /hardware/interfaces/nfc/1.1/INfc.hal
Android.bp
hidl_interface {
name: "android.hardware.nfc#1.1",
root: "android.hardware",
NxpService.cpp
Path: /hardware/nxp/nfc/1.1/NxpService.cpp
#include <android/hardware/nfc/1.1/INfc.h>
...
int main(){
sp<INfc> nfc_service = new Nfc();
status_t status = nfc_service->registerAsService();
android.hardware.nfc#1.1 would be at hardware/interfaces/nfc/1.1/ here.
The mappings for Android provided interfaces to their actual location are shown here https://source.android.com/devices/architecture/hidl/interfaces.
The files you look for are all auto-generated by hidl-gen, and they usually locate in out directory, e.g.
$ANDROID_ROOT/out/soong/.intermediates/hardware/interfaces/nfc/1.1/android.hardware.nfc#1.1_genc++_headers/gen/android/hardware/nfc/1.1
I have a very old C project that must be opened using borlandc. my machine runs win 8 so I have installed dosbox to run borlandc
the problem is that when i build the project, there exist too many errors, all are in the form: "unable to include file "xxx.h"
kindly be noted that:
- all these header files are existing in the INCLUDE folder
- I have created the cfg file and set the correct path to that folder for the compiler, so as for the linker
- I have set the environment variables
and still have the same errors
can anyone help me with that?
Check the bcc32.cfgfile.It must be in the same directory as that of the bcc32.exe file..
Check this here.
I think my question is pretty basic. I was trying to get Open CV to install on my OSX Lion. I had followed all the steps recommended on this link http://tilomitra.com/opencv-on-mac-osx/
However, when I run the C++ code recommended on the website in Xcode, it fails to load an image with the cvLoadImage( ) function. I have placed my image in the project folder (as recommended). Here is the code I was running:
// Example showing how to read and write images
#include <opencv2/opencv.hpp>
#include <opencv2/highgui/highgui.hpp>
#include <opencv/cvaux.hpp>
int main(int argc, char** argv)
{
IplImage * pInpImg = 0;
// Load an image from file - change this based on your image name
pInpImg = cvLoadImage("my_image.jpg", CV_LOAD_IMAGE_UNCHANGED);
if(!pInpImg)
{
fprintf(stderr, "failed to load input image\n");
return -1;
}
// Write the image to a file with a different name,
// using a different image format -- .png instead of .jpg
if( !cvSaveImage("my_image_copy.png", pInpImg) )
{
fprintf(stderr, "failed to write image file\n");
}
// Remember to free image memory after using it!
cvReleaseImage(&pInpImg);
return 0;
}
So during execution, the code builds successfully, but always ends up in the following loop and halts execution:
if(!pInpImg)
{
fprintf(stderr, "failed to load input image\n");
return -1;
}
Has anyone faced such a problem before? How could I solve this?
(During installation of 'Macports' and 'Cmake', I had received an alert saying that Xcode was not installed or was installed without 'Command Line Tools'. But as per another thread on this forum, I had installed these from the Xcode-->Preferences-->Downloads folder on installing Xcode.
However, still during installation, 'Macports' and 'Cmake' gave me warnings, but installed anyway. But could this be the issue? )
Thank you!
The problem is that you're putting the image into the project folder instead of the folder containing your executable. You can either put the image file in the folder with the executable or put the full path to the image in the call to cvLoadImage.
Older versions of Xcode put the executable in either the build/Debug or build/Release folder in the project folder. Newer versions of Xcode put the build products in the project folder in the DerivedData folder. You can find the DerivedData folder by going to File -> Project Settings… and clicking the arrow next to the folder path:
In the project folders, go to 'Products' > right click on the executable file > 'Show in Finder' > put the input image there. The output image ('.png' file) will go here as well.
I'm having a little trouble making my app bundle work from the terminal or just double clicking it.
This App actually compiles, links and runs perfectly within the Qt Creator IDE. But, if I try to open it from the terminal I get a "media/file.x file not found" error. The App bundle nor the /Contents/MacOS/executable is finding the "media" folder that is supposed to be beside the executable.
In my app I do something like:
openFile("media/file.x");
In Windows and Linux, this file WILL be found if the "media" folder is exactly in the same hierarchical position of the executable (beside it). On the Mac I have discovered it works differently cause Qt Creator builds an "App Bundle" and the actual executable is inside the /Contents/MacOS folder, so I copied the "media" manually there. This worked without any hassle when "playing" my app from the Qt Creator but as mentioned before it doesn't work when running the bundle itself.
So does anyone know where or how can I homogenize the look for this "media" folder so it works on both: Qt Creator and the App bundle?
Lately, I have been using the following command to "install" the folder on the bundle.
mac {
MediaFiles.files = media
MediaFiles.path = Contents/MacOS
QMAKE_BUNDLE_DATA += MediaFiles
}
Thanks for your help.
After looking for a few days I found a couple of posts discussing the relative path problem. I was just not searching with the right words... The answer is displayed in:
Relative Paths Not Working in Xcode C++
http://www.experimentgarden.com/2009/06/how-to-load-resource-from-your.html
Basically it is necessary to add this:
//On the include part
#ifdef __APPLE__
#include "CoreFoundation/CoreFoundation.h"
#endif
// On the main of your app
// This makes relative paths work in C++ in Xcode by changing directory to the Resources folder inside the .app bundle
#ifdef __APPLE__
CFBundleRef mainBundle = CFBundleGetMainBundle();
CFURLRef resourcesURL = CFBundleCopyResourcesDirectoryURL(mainBundle);
char path[PATH_MAX];
if (!CFURLGetFileSystemRepresentation(resourcesURL, TRUE, (UInt8 *)path, PATH_MAX))
{
// error!
}
CFRelease(resourcesURL);
chdir(path);
std::cout << "Current Path: " << path << std::endl;
#endif
// ----------------------------------------------------------------------------
IMPORTANT:
The chdir, changes the working path of the app, so it is not necessary to change you relative code after that...