#include search path saved in the work space.

Ideas for new features

Moderators: AmigoJack, bbadmin, helios, Bob Hansen, MudGuard

Post Reply
Mike
Posts: 3
Joined: Fri Nov 21, 2003 2:47 pm

#include search path saved in the work space.

Post by Mike »

As I understand it the search path for #includes found in a document comes from the enviroment.
However I have multiple instances of my SW tree and I'd like to be able to have my #includes come from my current branch, not the first instance found on my enviroment include path.
I think adding the #include path to the work space would allow me switch instances.

Thanks Mike
User avatar
ramonsky
Posts: 88
Joined: Fri Nov 14, 2003 10:54 am

Post by ramonsky »

I could be wrong, but I'm not entirely sure TextPad even HAS a concept of #include files. TextPad lets you edit the source files (for any language), but only a compiler (strictly speaking, a preprocessor) needs to know about an include path - and TextPad is not a compiler.

It might be possible, however, to achieve this goal in a slightly different way. This would still need a modification to TextPad, but a slightly different one from that which you suggest ... but it would have more applicability than just the scenario you suggest.

What you COULD do is to save a set of environment strings with a workspace. TextPad wouldn't have to understand the strings. (They could be, for example, "fish=haddock" or whatever). All it would have to do is make sure that that saved environment is passed onto the tools in the Tools menu. I think that would achieve your goal.

Jill
joel
Posts: 5
Joined: Wed Nov 19, 2003 7:53 pm

Post by joel »

I could be wrong, but I'm not entirely sure TextPad even HAS a concept of #include files.
It does. If you right-click on stdio.h in #include <stdio.h>, and either MSVC++ is installed or the INCLUDE environment variable is set correctly, TextPad will open the file.

My pet gripe with this feature involves the way I use it - I use MSVC++, cygwin, and MinGW32 about equally, each of which has a different include directory. Also, I have certain libraries that are shared between them (eg. Boost). I could start TextPad from a batch file (or a WinNT cmd file), but then I have to maintain seperate startup files for each compiler, and keep shared directories syncronized - ugh.

I'd prefer keeping the search path in TextPad's options anyway - some compilers like to follow environment variables. Also, this way the search path could be different for different file types - I'd like to right-click on import java.awt.Graphics and open the source for java.awt.Graphics, for example.

--Joel
Post Reply