Linux bluetooth development
 help / color / mirror / Atom feed
From: "Stotland, Inga" <inga.stotland@intel.com>
To: "michal.lowas-rzechonek@silvair.com" 
	<michal.lowas-rzechonek@silvair.com>
Cc: "linux-bluetooth@vger.kernel.org"
	<linux-bluetooth@vger.kernel.org>,
	"Gix, Brian" <brian.gix@intel.com>
Subject: Re: [PATCH BlueZ] mesh: Clean up includes
Date: Tue, 18 Jun 2019 15:49:49 +0000	[thread overview]
Message-ID: <6b160fc3a67b72495bd533a884ae7edd2d39c47b.camel@intel.com> (raw)
In-Reply-To: <20190618073559.tmpaj2oellkf5354@mlowasrzechonek2133>

[-- Attachment #1: Type: text/plain, Size: 2019 bytes --]

Hi Michal,

On Tue, 2019-06-18 at 09:35 +0200, Michał Lowas-Rzechonek wrote:
> Hi Inga,
> 
> On 06/17, Inga Stotland wrote:
> > This adds #include for json-c/json.h in mesh-db.h and removes this
> > include from the other files that don't need to reference json-c.
> 
> While I agree about removal from cfgmod-server, model and node, I
> don't
> think we should remove the include from storage and move it to mesh-
> db.
> 
> I'd rather see #includes follow https://include-what-you-use.org/
> approach, that is:
> 
>     (...) for every symbol (type, function variable, or macro) that
> you
>     use in foo.cc, either foo.cc or foo.h should #include a .h file
> that
>     exports the declaration of that symbol.
> 
> Moreover, I think headers should only be included as-needed (mostly
> in
> .c files), and headers should contain forward declarations of various
> types, to make them opaque.
> 
> Such an approach cuts implicit dependencies, making code maintenance
> easier: when, for example, someone decides to refactor mesh-db not to
> use json_object anymore, they shouldn't need to suddenly deal with
> missing declarations in other modules (in this case, storage).
> 
> Moreover, each header should be self-sufficient: in order to use API
> exposed by a given header, it should be enough to include that header
> only. At the moment, this is not the case.
> 
> A minor side-effect would be faster builds and less rebuilds when
> code
> is being worked on.
> 
> If you agree, I am more than happy to fix this throughout the mesh/
> codebase.
> 

I don't disagree, this was sort of an "intermediate" patch. I'd prefer
to remove the reference to json from storage.c and the rest of the code
 and localize it in only one file that would deal with json-related
processing.

So I might just as well go ahead and make mesh-db.h a generic API to
allow for different storage formats (even though for now we have only
json defined format).

Best regards,

Inga

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 3265 bytes --]

  reply	other threads:[~2019-06-18 15:49 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-17 21:38 [PATCH BlueZ] mesh: Clean up includes Inga Stotland
2019-06-18  7:35 ` Michał Lowas-Rzechonek
2019-06-18 15:49   ` Stotland, Inga [this message]
2019-06-19 17:44     ` michal.lowas-rzechonek

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=6b160fc3a67b72495bd533a884ae7edd2d39c47b.camel@intel.com \
    --to=inga.stotland@intel.com \
    --cc=brian.gix@intel.com \
    --cc=linux-bluetooth@vger.kernel.org \
    --cc=michal.lowas-rzechonek@silvair.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox