From: Jeroen Hofstee <dasuboot@myspectrum.nl>
To: u-boot@lists.denx.de
Subject: [U-Boot] [RFC] Proposal to change include search model
Date: Tue, 10 Jun 2014 22:40:29 +0200 [thread overview]
Message-ID: <1402432829.2437.62.camel@yellow> (raw)
In-Reply-To: <CA+gZxsOCK_izC7qOuWir_p4KoMso8r1dp6FBdzD-aB0sM2zbVw@mail.gmail.com>
On di, 2014-06-10 at 18:53 +0300, Vasili Galka wrote:
> Hi,
>
> Currently U-Boot has a long list of include search paths. This makes
> it hard to understand the location of each header. Moreover, it opens
> an easy opportunity for breaking build by including the wrong header.
> This is especially easy when compiling the tools directory. I found
> numerous commits dealing with such problems over the years.
>
> What I propose is changing the way of how #include directives are
> written. For example instead of:
>
> #include <stdlib.h> /* From toolchain */
> #include <api_public.h> /* include/api_public.h */
> #include <linux/mii.h> /* include/linux/mii.h */
> #include <config.h> /* Auto-generated somewhere */
> #include <bmp_logo.h> /* Auto-generated somewhere */
> #include <asm/arcregs.h> /* arch/arc/include/asm/arcregs.h */
> #include <asm/arch/emac_defs.h> /* arch/arm/include/asm/
> arch-davinci/emac_defs.h */
> #include "../../../../../drivers/net/davinci_emac.h"
>
> and let the developer guess the locations... I propose writing:
>
> #include <stdlib.h> /* <> means from toolchain */
> #include "inc/api_public.h" /* From u-boot/include/ dir */
> #include "inc/linux/mii.h"
> #include "config/config.h" /* From dedicated config dir */
> #include "generated/bmp_logo.h"
> #include "arch/asm/arcregs.h" /* From configured architecture */
> #include "soc/emac_defs.h" /* From configured SoC */
> #include "u-boot/drivers/net/davinci_emac.h"
>
> This way the developer will instantly know the exact header locations.
> Moreover, the chance for ambiguities is very small which makes build
> breakages less likely.
>
> The proposal may seem strange to you at first, as most of you are
> probably used to a different approach. But please consider its
> advantages. I've been working on projects that used similar scheme
> and it significantly simplifies the developer life.
>
> The above can be implemented by creating
> inc/ arch/ soc/ u-boot/
> filesystem links in ${objtree}/include. Then, the only compiler flag
> required will be "-iquote ${objtree}/include". No ugly -idirafter flags,
> no long search list. Keep it simple.
>
> I'll be glad for your opinions!
>
This sounds way too complex if you ask me for what your are trying to
fix. For one thing #include<> versus include "" is compiler specific and
not defined in general. If I find some time I will see if I can find
another solution for it. But you're warned heads up that it might
include one additional -I for standard c libraries for the target (which
is only errno.h at the moment, afaik) ;)
Regards,
Jeroen
next prev parent reply other threads:[~2014-06-10 20:40 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-10 15:53 [U-Boot] [RFC] Proposal to change include search model Vasili Galka
2014-06-10 20:40 ` Jeroen Hofstee [this message]
2014-06-12 8:51 ` Vasili Galka
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1402432829.2437.62.camel@yellow \
--to=dasuboot@myspectrum.nl \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.