Re: [edk2-devel] [PATCH edk2-InfSpecification] Drop statement on package ordering

["Pankaj Bansal" <pankaj.bansal@nxp.com>]

> >>
> >> (since I've been copied)
> >>
> >> I have not been aware of the header name collision scenario (nor that
> >> the [Packages] ordering was supposed to work around such issues).
> >>
> >> I work strictly with edk2 proper, where a name collision like this can
> >> be detected, and so should be prevented. (Insert yet another argument
> >> why keeping platform code outside of edk2 is a bad idea.) In particular,
> >> a collision between MdePkg and MdeModulePkg would be super bad.
> >>
> >> Which now seems to turn out consistent with my general review point that
> >> the [Packages] section, like (almost) all other INF file sections,
> >> should be sorted lexicographically.
> >>
> >> How about replacing
> >>
> >> """
> >> Packages must be listed in the order that may be required for specifying
> >> include path statements for a compiler. For example, the
> MdePkg/MdePkg.dec_
> >> file must be listed before the `MdeModulePkg/MdeModulePkg.dec` file.
> >> """
> >>
> >> with
> >>
> >> """
> >> The order in which packages are listed may be relevant. Said order
> >> specifies in what order include path statements are generated for a
> >> compiler. Normally, header file name collisions are not expected between
> >> packages -- they are forbidden in edk2 proper --, but with a module INF
> >> consuming both edk2-native and out-of-edk2 packages, header file names
> >> may collide. For setting specific include path priorities, the packages
> >> may be listed in matching order in the INF file. Listing a package
> >> earlier will cause a compiler to consider include paths from that
> >> package earlier.
> >> """
> >
> > Nicely summed up! it is much clearer now for anyone like me who wants to
> port edk2 for his platform.
> > one more suggestion. should this be mentioned along with above explaination:
> > "whenever possible use lexicographically ascending order"
> 
> I'd love that, but it's really just a policy question that I prefer.
> 
> If we tried to elevate my preference to official edk2 spec level, it
> could run into opposition (like any other proposal -- so that would be
> just fine, per se!). I just wouldn't like to delay the more important
> clarification with a discussion around my preference.
> 
> So minimally, that would take a two-part patch series, and even so the
> second patch would likely have to be marked RFC. I think we can simply
> postpone the official speccing of the lexicographical sorting idea
> (indefinitely, even).

The point that I want to make is that these document should guide new
developers, as to how to contribute to edk2 code as well as explaining how
edk2 code has been organized.

To explain a practice historically followed in edk2 (but no longer followed),
is informercial to new developers. but it is of little help for them to contribute to edk2.

perhaps along the edk2 c guidelines, there should be a section in each specification
file, titled Guidelines ?

> 
> Thanks
> Laszlo