From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: storm@cua.dk (Kim F. Storm) Newsgroups: gmane.emacs.devel Subject: Status of MAC/W32/X consolidation and some questions. Date: 10 Mar 2003 13:13:20 +0100 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <5xadg38lnj.fsf@kfs2.cua.dk> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1047295076 27392 80.91.224.249 (10 Mar 2003 11:17:56 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 10 Mar 2003 11:17:56 +0000 (UTC) Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Mon Mar 10 12:17:54 2003 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 18sLI2-00077Z-00 for ; Mon, 10 Mar 2003 12:17:54 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 18sLeG-00018M-00 for ; Mon, 10 Mar 2003 12:40:53 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18sLGp-0001QB-03 for emacs-devel@quimby.gnus.org; Mon, 10 Mar 2003 06:16:40 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13) id 18sLGP-0001NK-00 for emacs-devel@gnu.org; Mon, 10 Mar 2003 06:16:13 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 18sLGJ-0001Hw-00 for emacs-devel@gnu.org; Mon, 10 Mar 2003 06:16:08 -0500 Original-Received: from mail.filanet.dk ([195.215.206.179]) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18sLEh-0000bs-00 for emacs-devel@gnu.org; Mon, 10 Mar 2003 06:14:27 -0500 Original-Received: from kfs2.cua.dk.cua.dk (kfs2.local.filanet.dk [192.168.1.182]) by mail.filanet.dk (Postfix) with SMTP id 5A3F57C012 for ; Mon, 10 Mar 2003 12:14:23 +0100 (CET) Original-To: emacs-devel@gnu.org Original-Lines: 95 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Emacs development discussions. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:12223 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:12223 [There are a couple of MAC and W32 specific questions in this mail. Those who know these ports well, please take a look at them.] As you may have seen on emacs-devel, I'm in the process of consolidating the various ports of CVS emacs for X, W32, and MAC. Most of this work is to identify (and merge) code which basically only differs in "names" rather than "structure", e.g. by using FRAME_X_P in the X version, and FRAME_MAC_P in the MAC version, but otherwise is identical. AFAICS, the best option for maximum code sharing is to extend the current approach in the MAC and W32 ports of using part of the X port name space, e.g. by defining a partial x_output structure to satisfy the needs of the basic code which expects an x_output structure to exist, or by defining some of the FRAME_X_* macros to point to the output_data.mac structure. Now, what I'm currently working on is to replace all mac* and w32* specific names with the corresponding x* names, e.g. FRAME_MAC_WINDOW is replaced by FRAME_X_WINDOW, mac_output is replaced by x_output, f->output_data.mac becomes f->output_data.x, etc. etc. As I progress in this regard, the amount of code which can then be shared directly between the ports gets larger and larger. One major drawback of this approach is that while the current "overloading of the X* specific names makes it difficult to make a version which supports both MAC and X simultaneously (i.e. in the same executable), extending this "overloading" to cover all the MAC and W32 specific code makes it practically impossible to support such cross-GUI systems that later on. However, I got the message from RMS, that this limitation was acceptable (and I agree), so I'm doing just that, as it gives the maximum benefits with the least amount of work (still it *is* a lot of tedious work :-) However, one of the "merged" macros is giving me problems: FRAME_MAC_P and FRAME_W32_P cannot simply be merged into FRAME_X_P (for various reasons), but I'll find a way :-) On W32, FRAME_W32_P seems to be true even when HAVE_NTGUI is not defined (at lease Fframe_parameter in frame.c seems to assume this), so while FRAME_X_P and FRAME_MAC_P means that the output is to a GUI, FRAME_W32_P only means that output is to a w32 system as such. So my questions to the W32 experts are: * Does it make sense to build NTemacs without HAVE_NTGUI defined? Is it possible to do that? * Does the W32 version support -nw? If so, is FRAME_W32_P still true when specified? On MAC, I noticed two places in macterm.c where FRAME_X_P is tested rather than FRAME_MAC_P, which basically means that the corresponding code _IS_NOT_ executed: * In x_flush, the call to XFlush is conditioned by FRAME_X_P * In XTframe_up_to_date, the entire code is conditioned by FRAME_X_P. Could a MAC expect please check these two strange-looking cases for me, thanks! Also on MAC, there are quite a number of TODO items, meaning that some section of more-or-less unmodified X or W32 code is commented out with #if 0... #endif. In the cases where the code is to be "consolidated", I would prefer to leave a TODO note in the mac* file and simply delete the code from the file. Then in the consolidated code file, I will put a #ifndef MAC_OS around the consolidated code to indicate that it is not used on MAC_OS (yet). Is that an acceptable approach? Since I'm working on this right now, I would advise everyone to commit any major changes that you may have in your local checkout, as the structure of the code is going to change quite a lot due to my work (the consolidated code is going to be moved out of the mac* specific files). Also, since I cannot really test the changes on MAC and W32, I do expect that I'm going to make a few mistakes in the consolidation, resulting in non-functional MAC and W32 versions on the CVS head, which I hope some of you will assist me in solving (I hope/expect it is just a matter of fixing some trivial compilation errors). -- Kim F. Storm http://www.cua.dk