CompuServe Thread

#C++ Compile stages…

4 messages in this thread
#7259From: Andrew CarolJul 20, 1993 10:34 PM
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
#7270From: Reede StocktonJul 21, 1993 12:39 AM
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
#7272From: Andrew CarolJul 21, 1993 1:14 AM
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
#7344From: Reede StocktonJul 21, 1993 11:02 PM
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