From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.schemamania.org (rrcs-50-75-19-234.nys.biz.rr.com [50.75.19.234]) by sourceware.org (Postfix) with ESMTP id 1681A3858C33 for ; Thu, 1 Dec 2022 16:43:28 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 1681A3858C33 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=schemamania.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=schemamania.org Received: from oak.schemamania.org (localhost [IPv6:::1]) by mail.schemamania.org (Postfix) with ESMTP id AEF2A256FABB; Thu, 1 Dec 2022 11:11:26 -0500 (EST) Date: Thu, 1 Dec 2022 11:11:26 -0500 From: "James K. Lowden" To: Michael Matz Cc: gcc@gcc.gnu.org Subject: Re: access to include path in front end Message-Id: <20221201111126.3c0789057cdd420d930836a0@schemamania.org> In-Reply-To: References: <20221129100804.c5b3e5bc669ff92f2100c3a3@schemamania.org> X-Mailer: Sylpheed 3.4.3 (GTK+ 2.24.28; x86_64--netbsd) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,NICE_REPLY_A,PDS_RDNS_DYNAMIC_FP,RDNS_DYNAMIC,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Wed, 30 Nov 2022 15:58:40 +0000 (UTC) Michael Matz wrote: Hi Michael, First, thanks for a great answer, and to Jonathan for reminding me of what documentation we do have for this. I'm now using -I in cobol1, but I'm not getting it from gcobol. I guess I need to extend the spec options, but I'm puzzled because so far I've been able to dodge that bullet. > E.g. look in gcc.cc for '@c' (matching the file extension) how that > entry uses '%(cpp_unique_options)', and how cpp_unique_options is > defined for the specs language: > > INIT_STATIC_SPEC ("cpp_unique_options", &cpp_unique_options), > > and > > static const char *cpp_unique_options = > "%{!Q:-quiet} %{nostdinc*} %{C} %{CC} %{v} %@{I*&F*} %{P} %I\ Please tell me if this looks right and complete to you: 1. Add an element to the static_specs array: INIT_STATIC_SPEC ("cobol_options", &cobol_options), 2. Define the referenced structure: static const char *cobol_options = "%{v} %@{I*&F*}" or just static const char *cobol_options = "%{v} %@{I*}" because I don't know what -F does, or if I need it. I'm using "cobol_options" instead of "cobol_unique_options" because the options aren't unique to Cobol, and because only cpp seems to have unique options. I'm including %{v} against the future, when the cobol1 compiler supports a -v option. 3. Correct the entries in the default_compilers array. Currently I have in cobol/lang-specs.h: {".cob", "@cobol", 0, 0, 0}, {".COB", "@cobol", 0, 0, 0}, {".cbl", "@cobol", 0, 0, 0}, {".CBL", "@cobol", 0, 0, 0}, {"@cobol", "cobol1 %i %(cc1_options) %{!fsyntax-only:%(invoke_as)}", 0, 0, 0}, That last one is a doozy. Is it even slightly right? IIUC, I should at least remove %{!fsyntax-only:%(invoke_as)} because I don't need the options from the invoke_as string in gcc.cc. (Actually, we do have a syntax-only feature. IIUC, the we could define our own command-line options to invoke it, and use our own static variable cobol_foo (instead of invoke_as) to pass those options to cobol1 when -fsyntax-only is used. Or, alternatively, we could just honor -fsyntax-only literally, like any other option.) That would still leave me with too much, because cobol1 ignores most of the options cc1 accepts. What would you do? I don't understand the relationship between default_compliers and static_specs. I have made no special provision for "compiler can deal with multiple source files", except that cobol1 accepts multiple source files on the command line, and iterates over them. If that's enough, then I'll set compiler::combinable to 1. I'm trying those 3 today. I'd like to get it right, as long as I'm in the neighborhood. :-) +++ As I mentioned, for a year I've been able to avoid the Specs Language, apparently because some things happen by default. The options defined in cobol/lang.opt are passed from gcobol to cobol1. The value of the -findicator-column option is available (but only if the option starts with "f"; -indicator-column doesn't work). cobol1 sees the value of -fmax-errors. Is that because I'm using gcobol, and not "gcc -x cobol" ? If not, how do I know what's passed by default, and what needs specification? Thanks again for your guidance. I doubt I'll ever really understand what's going on at this level, but I'm glad to plug in the right magic values. Regards, --jkl