"Reorganization" of the modules as they are currently defined in IETF is required in order to avoid the "circular import" error reported by the ConfD compiler (e.g. confdc of TailF). I guess that when we remove this restriction (as far as I remember, a #include equivalent is possible in C/C++) then at least the modules compile in its current form (that means after correcting the calls to derived-from-or-self to having only parameters instead of 3 as they are currently defined in the IETF modules). I agree that this is not related to the comment made whether re-organizing iana-entities in such a way that it defines the identity (rather then importing it from ietf-entity).
Best regards - Vriendelijke groeten, Bart Bogaert Broadband-Access System Architect Data Contact number +32 3 2408310 (+32 477 673952) NOKIA Copernicuslaan 50, 2018 Antwerp, Belgium Fortis 220-0002334-42 VAT BE 0404 621 642 Register of Legal Entities Antwerp << This message (including any attachments) contains confidential information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, you should delete this message. Any disclosure, copying, or distribution of this message, or the taking of any action based on it, is strictly prohibited without the prior consent of its author. >> -----Original Message----- From: Juergen Schoenwaelder [mailto:[email protected]] Sent: 29 August 2016 09:27 To: Bogaert, Bart (Nokia - BE) Cc: Martin Bjorklund; [email protected] Subject: Re: [netmod] derived-from-or-self leads to circular import I fail to see what this thread has to do with circular imports. /js On Mon, Aug 29, 2016 at 07:17:58AM +0000, Bogaert, Bart (Nokia - BE) wrote: > Just taking another approach on this: why do we have the restriction > on circular imports? Is this really required? If not then this may > be solved in another way too (but will take some time before it gets > into the YANG compilers I'm afraid). > > Best regards - Vriendelijke groeten, > Bart Bogaert > Broadband-Access System Architect Data Contact number +32 3 2408310 > (+32 477 673952) > > NOKIA > Copernicuslaan 50, 2018 Antwerp, Belgium Fortis 220-0002334-42 VAT BE > 0404 621 642 Register of Legal Entities Antwerp > > << > This message (including any attachments) contains confidential > information intended for a specific individual and purpose, and is > protected by law. If you are not the intended recipient, you should > delete this message. Any disclosure, copying, or distribution of this > message, or the taking of any action based on it, is strictly > prohibited without the prior consent of its author. > >> > > > -----Original Message----- > From: Martin Bjorklund [mailto:[email protected]] > Sent: 26 August 2016 14:33 > To: [email protected] > Cc: Bogaert, Bart (Nokia - BE); [email protected] > Subject: Re: [netmod] derived-from-or-self leads to circular import > > Juergen Schoenwaelder <[email protected]> wrote: > > On Fri, Aug 26, 2016 at 12:43:04PM +0200, Martin Bjorklund wrote: > > > Juergen Schoenwaelder <[email protected]> wrote: > > > > On Fri, Jul 29, 2016 at 12:50:13PM +0000, Bogaert, Bart (Nokia - > > > > BE) > wrote: > > > > > > > > [...] > > > > > > > > > In order to correctly compile (using confdc) we also need to > > > > > import iana-entity for the identities defined in there. > > > > > However this is leading a circular dependency: > > > > > > > > > > 1. Iana-entity imports ietf-entity (to 'resolve' > > > > > entity-physical-class) > > > > > > > > > > 2. Ietf-entity imports iana-entity (to obtain the indentities > defined > > > > > in there) > > > > > > > > > > One way to solve this is to move the definition of > > > > > entity-physical-class from ietf-entity to iana-entity which > > > > > would resolve the fact that iana-entity requires an import of > > > > > ietf-entity (ietf-entity needs to import iana-entity anyhow, > > > > > so it can also pick the typedef from the same module too). > > > > > > > > I think moving the definition of entity-physical-class into > > > > iana-entity makes sense. > > > > > > Ok. It feels a bit backwards to me though, but I can see the > > > value of having the iana module self-contained. > > > > > > > Well, it may look backwards if people want to reuse the base > > identity but none of the IANA assigned identities - but then it > > might be good if people at least look at IANA assigned identities. > > Or are there other reasons why you think this may be looking 'backwards'? > > I makes ietf-entity dependent on iana-entity, since the base identity > is defined in iana-entity. > > But OTOH, even if we solved that, ietf-entity is dependent on > iana-entity b/c of the value 'sensor'. > > So in this case it is probably fine, but I'm not sure about the > general idea. > > > /martin -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <http://www.jacobs-university.de/>
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
