The Carbon build uses the SIOUX libraries to implement a rather primitive console, which is inaccessible during debugging (can't scroll, respond to events). I've checked in a new file that when used instead of the SIOUX library, sends a stdio to the System Console application or to the current terminal, when debugging with gdb, or when launching from the command line. The new file is checked in as: mozilla/lib/mac/NSStdLib/src/MacOSX_Console.cpp To use it, you remove the SIOUX source files from the NSStdLibCarbonDebug.shlb target of NSStdLib.mcp. I will enclose the edited project file as an attachment.
Can we rig the carbon target to just do the right things on Mac OS 9 and X, i.e. to make a console window on 9, and go to the terminal on X?
Well, since our Carbon build is OS X only, I'm not sure this is worth the effort.
But it's not! Witness Conrads efforts to build the embedding sample for Carbon. We cannot assume that TARGET_CARBON==Mac OS X
I agree that assuming TARGET_CARBON==Mac OS X is bad. The Carbonized embedding sample is beside the point. It would be nice if we *could* run Carbon under 9 at some point. We certainly don't want to add more code which will make this less likely. Besides, how hard is it to call Gestalt?
Calling Gestalt isn't the issue, having to write two sets of console hooks in the same binary is a pain. We may have to change some SIOUX code to make this work. I guess I could put the SIOUX hooks in a separate shared library, and load those dynamically if need be. I agree that TARGET_CARBON doesn't imply Mac OS X, except for just right now. I'll ponder the right way to integrate this.
How about just having proc ptrs, initialized once depending on what system we're on? The calls have to come through the console_stubs.c routines, but just vector them from there.
I checked in a shared library version of SIOUX, that now gets dynamically loaded by InstallConsole() if the system version is < 0x00001000. The new project files are here: mozilla/lib/mac/NSStdLib/NSConsole.exp mozilla/lib/mac/NSStdLib/NSConsole.mcp Now we just need build system changes to build this library.
Awesome. The system console will be ideal under OS X. Since you did the good thing of having an external (I hope its external) shared lib, I (and anybody who wants) can just replace the dreaded SIOUX component with something better.
Yes I use CFM to open the library dynamically. The external library must have the fragment name "NSConsole" and it must have the following exports: InstallConsole RemoveConsole WriteCharsToConsole ReadCharsFromConsole SIOUXHandleOneEvent SIOUXIsAppWindow SIOUXSettings I had to add SIOUXIsAppWindow this morning, since it is being used by macstdlibextras.c in my most recent pull (this morning).
*** Bug 83539 has been marked as a duplicate of this bug. ***
I've found a way to distinguish between stderr and stdout, by taking over the I/O vectors called __read_console() & __write_console(). I've checked this into the latest version of MacOSX_Console.cpp. To use this, the file console_io.mac.c needs to be removed from the target NSStdLibCarbonDebug target of NSStdLib.mcp.
Created attachment 42711 [details] [diff] [review] Build system changes to build NSConsole.mcp for external SIOUX console.
I need a reviewer and super reviewer to check these in on the trunk.
Changes checked in on trunk.
Status: NEW → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED
And by doing so you broke the mac build and then left it broken. Not nice. I tried to fix it by adding back the ContextualMenu library as it was before. I have no idea if that's right and whether you really wanted to remove it or just disable it in some targets.
For future reference, the correct way to fix linkage problems when dealing with Mac specific shared libraries, is to add them to the common stub library here: mozilla/lib/mac/InterfaceLib/Interface.mcp So, if I'd been called about the bustage, I would have put ContextualMenuLib in that library instead of readding it to NSStdLib.mcp. As it is, I will have to do this, because we shouldn't link the Carbon version of NSStdLib.shlb against ContextualMenuLib, because it isn't a Carbon library.
You need to log in before you can comment on or make changes to this bug.