gm2
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Substituting local modules with the same name as the GM2 modules


From: Gaius Mulley
Subject: Re: Substituting local modules with the same name as the GM2 modules
Date: Fri, 17 Nov 2023 13:33:51 +0000
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux)

Benjamin Kowarsch <trijezdci@gmail.com> writes:

> Simply get rid of the local modules.
>
> They can easily be copy pasted out into a separate file and made into 
> separate modules. Any entities that are used by the surrounding module can be 
> defined
> in a definition module and exported. The former hosting module can then 
> import those identifiers back in.
>
> Local modules should never have been part of the language. This was one of 
> those silly fads of the 1970s where everybody and their dog wanted to make
> everything "orthogonal" even if there was absolutely no reason to do so, even 
> when doing so would come with a long list of disadvantages, even if doing so
> unnecessarily increased complexity. Just get rid of them.
>
> On Fri, 17 Nov 2023 at 07:46, john o goyo <jog37@riddermarkfarm.ca> wrote:
>
>  Greetings, Gaius.
>
>  I am trying to build some old code that uses a different version of 
>  Storage.  I have a local version to reflect this and I am using the "-I" 
>  directive.  The compiler picks up my local version for compiling local 
>  modules but it also uses my local version for gm2 modules.
>
>  In particular, examining m2/m2pim/Indexing.def pulled in my local 
>  Storage.def and failed.
>
>  Hence my query:  Is it even possible to instruct the compiler to use 
>  local modules for local compilation only (or must I rename them)?
>
>  Sincerely,
>  john

Hi Benjamin and John,

ah interesting - I interpreted the mail as querying a storage definition
module in a local directory.  (But I concur with the criticism of local
modules per se - the knock on effect of local modules and enumerated
field visibility can become unpleasant to implement).

If the issue is a storage definition module in a local directory then I
wonder if: -fno-extended-opaque might help?

What does:

$ gm2 -c -I<paths etc> -fno-extended-opaque -fno-m2-whole-program \
  -fno-scaffold-main -fsources modulename.mod

display?  Is Indexing.mod parsed?  I suspect that something is provoking
gm2 to examine the implementation module (-fextended-opaque and
-fm2-whole-program would cause this - and also when compiling program
module and building the scaffold as it resolves the initialization order
via import analysis).

During compilation the compiler assumes one version of a module in its
visible universe (using -I per compilation per module).  But it can link
multiple versions of modules as directory paths can be named.
This occurs in the default libraries to allow different dialects of
libraries to coexist - (for example m2pim_Storage_ALLOCATE and
m2iso_Storage_ALLOCATE)

hope this helps?

regards,
Gaius



reply via email to

[Prev in Thread] Current Thread [Next in Thread]