The current method the command Quick Open of the C bundle does use is look for the file in several funny directories that not always are then same c/c++ are looking into.
Is not easy to know where the cpp preprocessor look for the included files. The only method I have found is from Andrew Tomazos and is a small Perl script that makes c++ have mistakes and then shows us the real places where it is looking into.
Running it once is enough, I think, and then pick up the directories for a script to quick opening included files.
I would like to know who is the C bundle maintainer for to share this things with him.
I also find a bit complicated the current way of making changes (yet small changes) and then you will be out of updates of the official bundle since yours will be always loaded before the official one.
Tx.
#!/usr/bin/env perl
$line=$ENV{'TM_CURRENT_LINE'}; $header=$ENV{'TM_SELECTED_TEXT'};
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; } }
@incs = qw( /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 );
foreach $t (@incs) { if (-f "$t/$header") { print "$t/$header"; system("mate -r "$t/$header""); exit 0; } } print ""; exit 1;
On Apr 19, 2007, at 11:51 AM, Juan Falgueras wrote:
Is not easy to know where the cpp preprocessor look for the included files.
@incs = qw( /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 );
It would be really _really_ cool if you could specify (via an environmental variable) where to look for include files (think basically a duplication of the search paths you pass to gcc/XCode).
Something like:
TM_HEADER_SEARCH_PATHS = /opt/local/include/:~/Projects/common/headers
(where the colon is the separator between items, being one of the few illegal characters in the Mac OS file system).
You could also do relative paths, being relative to TM_DIRECTORY/ TM_PROJECT_DIRECTORY.
These would then get exploded into a list and added on to @incs here
Hope this helps, _Ryan Wilcox
On 19. Apr 2007, at 18:19, Ryan Wilcox wrote:
[...] It would be really _really_ cool if you could specify (via an environmental variable) where to look for include files (think basically a duplication of the search paths you pass to gcc/XCode).
That’s a very good idea, especially since we can set variables for folders, so I can have project A know about headers for the fraeworks used by this project.
On 19. Apr 2007, at 17:51, Juan Falgueras wrote:
The current method the command Quick Open of the C bundle does use is look for the file in several funny directories that not always are then same c/c++ are looking into.
Yeah, I must confess I find the command in its current form not very useful, as it fails for me half the time, and it is pretty slow.
[...] I would like to know who is the C bundle maintainer for to share this things with him.
That would be Chris Thomas and I, I think Chris was responsible for the last iteration, where Spotlight querying was introduced.
But I’d gladly rework the command if we can agree on a defined behavior -- as mentioned in the other reply, I really like the idea of giving (additional) search path through an environment variable. Also, with tm_dialog we can now show a neat pop-up menu, rather than open all found headers as a project.
I also find a bit complicated the current way of making changes (yet small changes) and then you will be out of updates of the official bundle since yours will be always loaded before the official one.
No, only the item you actually changed, will no longer be updated. So if you locally improve the Quick Open command, you will still see updates to all the other things in the C bundle.
On Apr 19, 2007, at 12:44 PM, Allan Odgaard wrote:
That would be Chris Thomas and I, I think Chris was responsible for the last iteration, where Spotlight querying was introduced.
Yup, and I think I also created the original implementation. I agree the Spotlight version is really slow, though it does always find what I'm looking for.
But I’d gladly rework the command if we can agree on a defined behavior -- as mentioned in the other reply, I really like the idea of giving (additional) search path through an environment variable.
I think that's a good idea. I'd also like to see a settings dialog with preferences:
- a default SDK to search (one of the folders in /Developer/SDKs/ or system root) - a global list of paths to search for headers, with a checkbox column to disable ones you don't want - perhaps a compiler version, some include paths would change based on this
Chris