#C++ Compile stages…
4 messages in this thread
Hi Ho!
C++ programs should go through at least three stages. Pre-proccess, compile,
and link. Is there a way using Symantec C++ to add an extra step? Can I write
a tool which will receive the prior steps output and pass it modified on to the
next step?
Specificly what I want to do is to add a pre-pre-proccesser step. I want to
massage the source, then let Symantec C++ take over. Of course I don't want to
write these changes back to the source file. This is a compile only thing.
Will the scripting feature allow this. Is it hopeless?
Thanks! Cheers!
—- Andrew
Andrew,
"Specificly what I want to do is to add a pre-pre-proccesser step. I want to
massage the source, then let Symantec C++ take over."
This is still your path problem, right?
There are a couple of scripting-type things you might try. I'm going to talk
about Frontier since that's what I know and like the best. I'll leave
AppleScript comments to someone else. With Frontier menu-sharing you can
specify command-keys. What that would essentially allow you to do is invoke
any script as an override to cmd-U or cmd-K. Then you could invoke the compile
or bring-up-to-date from the script. You could write either a UCMD or a simple
AppleEvent-driven program to parse your files making the necessary changes.
One gotcha with this is that I do not believe TPM can be queried about header
files (makes sense — they're not in the project and are only visible when
parsed), so you would have to find them yourself. This strategy obviously has
the drawback you were hoping to avoid — modification (at least temporarily) of
source files.
If I were going to try to solve this problem, I think I would adopt a slightly
different strategy. Essentially, I would try to drive or hook into the process
of moving your files to and from their unix homes. A Frontier agent can
monitor the contents of a folder searching for new files. What I might try is
to set up such an agent to convert the paths when files are moved in. Then
re-convert the paths when they are moved out. Frontier has file read and write
routines, but they're really not meant for high volume stuff, so you'd probably
want to write your own parser which can be invoked by the script. If you
handle it this way, you don't have to intervene in the build/link process at
all. Once again, though, you'd obviously be modifying source code.
Reede
Thanks for the reply about inserting myself into the compile cycle. You were
on target about doing this for the "slash in path name" issue.
My hope had been to, in effect, pipe source through me to the pre-proccesser
makeing changes as needed. Under UNIX this would not have been hard. Making
real changes in source files in not going to work. Too delicate.
I gather that the connection between the preprocceser and the compiler in
Symantec C++ is completely closed and private?
My three options now:
1) Try some compile time trick to massage the path names.
2) Patch the File Traps to accept path names with slashes.
3) Use some kind of portable macro to build include paths.
4) Pray Bedrock will actually allow me to use the tools that even the DOS world
takes for granted.
5) Ignore the problem.
There has actually been a tiny little bit of support for option 3 at work,
(Suprise!). I would prefer option 1, as it is the most elagant. Option 2 is
probably the path of destruction.
Oh well, thanks anyway!
Cheers! 🙂
—— Andrew
Andrew,
"I gather that the connection between the preprocceser and the compiler in
Symantec C++ is completely closed and private?"
I don't know the internals of the Symantec compiler, but there is no separate
pre-processor as in an AT&T style C++ pre-processor which spits out C code.
Obviously, there's some internal magic happening to deal with classes &
defines, but yes, it is seen by the user as a completely enclosed unit. Do
other native C++ compilers (as opposed to CFront-style pre-processors) work
differently than this?
"Making real changes in source files in not going to work. Too delicate."
I'm a bit befuddled by why you think massaging paths in a source file is more
delicate than patching file traps or massaging paths at compile time, but
that's your call.
Good luck! It's good to hear that you had some support for the macro idea.
Reede