De: Allan Odgaard <throw-away-1@macromates.com>
Fecha: 23 de abril de 2007 03:03:18 GMT+02:00
Para: TextMate users <textmate@lists.macromates.com>
Asunto: Re: [TxMt] QuickOpen included files
Responder a: TextMate users <textmate@lists.macromates.com>
On 20. Apr 2007, at 20:59, Juan Falgueras wrote:
I have change the source of the list of paths for QuickOpen included files. It works fine:
Thanks, seems to work fine here as well. Some comments:
• we should differ between <system> and "user" include paths
actually the script does consider <system> and "user" paths and get first the "user" path not looking for TM_HEADER.. when "user"
if (!$header) {
$line =~ /#\s*include\s*([<"])(.*?)[">]/;
$local = $1;
$header = $2;
}
if ($local eq '"') {
$t = $ENV{'TM_DIRECTORY'};
if (-f "$t/$header" ) {
print "$t/$header";
system("mate -r \"$t/$header\"");
exit 0;
}
}
• TM_HEADER_SEARCH_PATHS should default to the output from gcc/g++ (to not require user setup)
I have thought about it but, when? If you ask for echo | g++ -E -v -x c++ - and then analyze the output (with the A.Tomazos perl script, for example), you then don't want any TM_HEADER_SEARCH_PATHS, but instead, to call to the g++ compiler for this. I've thought this must be slow, and the answer to the previous query is near always the same.
• search path could depend on whether we are in source.c or source.c++ (the former has a smaller search path)
yes. The difference is (in my system):
C++
/usr/include/c++/4.0.0
/usr/include/c++/4.0.0/powerpc-apple-darwin8
/usr/include/c++/4.0.0/backward
/usr/local/include
/usr/lib/gcc/powerpc-apple-darwin8/4.0.1/include
/usr/include
/System/Library/Frameworks
/Library/Frameworks
versus
C
/usr/local/include
/usr/lib/gcc/powerpc-apple-darwin8/4.0.1/include
/usr/include
/System/Library/Frameworks
/Library/Frameworks
I have used the most frequently used C++ :)
• additional search paths should be taken from the current Xcode project file, if any (and Xcode’s products build dir should also be a search path for frameworks)
oups! don't use XCode, sorry. I think it must be done asking XCode (via AS) or hacking the XCode project file... (complicated and dirty) :(
• need to handle framework inclusion, e.g. <Cocoa/Cocoa.h>
you are again wright:
% locate Cocoa.h
/Developer/ADC Reference Library/documentation/Cocoa/Cocoa.html
/Developer/ADC Reference Library/documentation/Cocoa/Conceptual/CarbonCocoaDoc/Articles/CarbonInCocoa.html
/Developer/ADC Reference Library/documentation/Cocoa/Conceptual/CarbonCocoaDoc/Articles/CarbonUIInCocoa.html
/Developer/SDKs/MacOSX10.3.9.sdk/System/Library/Frameworks/Cocoa.framework/Versions/A/Headers/Cocoa.h
/Developer/SDKs/MacOSX10.3.9.sdk/System/Library/Frameworks/JavaEOCocoa.framework/Versions/A/Headers/EOCocoa.h
/Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/Cocoa.framework/Versions/A/Headers/Cocoa.h
/Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/JavaEOCocoa.framework/Versions/A/Headers/EOCocoa.h
/System/Library/Frameworks/Cocoa.framework/Versions/A/Headers/Cocoa.h
is not found by this simple script and there are:
% find /System/Library/Frameworks/ -iregex ".*\/Headers\/.*\.h" | wc -l
2112
many.
It was not a problem for me since I am working in a UNIX standard programming way...
• need to handle import as well as include (in the regexp)
is is easy to add it
And if I understood Chris correctly, he’d like to optionally search under /Developer/SDKs/«chosen SDK».
As far as I have understood this is included in your Frameworks plus XCode dirs expansion search
Are there other things we’d like to support?