In reply to this post by Enrico Weigelt, metux IT consult
On 7/21/2017 12:20 PM, Enrico Weigelt, metux IT consult wrote:
> Hi folks,
> I've observed that most of the #include directives are w/o directory
> names. So, we need lots of -I flags of #ifdef's around them.
> As I'd suspect, the directory layout doesn't change frequently,
> I'd suggest cleaning that up step by step.
> Eg. instead of
> #include "GMPService.h"
> #include <dom/media/gmp/GMPServiceChild.h>
There are two problems with this:
1. There is a slight difference between #include <> and #include "" in
terms of search paths. In general, it's a better idea to use the quotes
for files in the same repository.
2. The build system has an export step which collects most of the
includes into a single directory that is added to the -I flag for all
builds ($objdir/dist/include). This is done for modularity, and to
distinguish between "internal" headers (that shouldn't be used outside a
module) and "external" headers. The dom/ path is clearly relative to
nothing (except the topsrcdir of mozilla-central, which I'm not sure is
even in the -I path in the first place).
As has been noted, you're really asking about mozilla-central-related
questions, for which this is not the appropriate forum.
Thunderbird and DXR developer
Source code archæologist
> 1. There is a slight difference between #include <> and #include "" in
> terms of search paths.
IIRC, <> should prefer include dirs over current dir, IMHO.
It could find them also in system include dirs, if they were there.
But is that a problem ?
> In general, it's a better idea to use the quotes
> for files in the same repository.
Agreed. But my main point was using full directory names.
Lots of files are already doing that.
> 2. The build system has an export step which collects most of the
> includes into a single directory that is added to the -I flag for all
> builds ($objdir/dist/include). This is done for modularity, and to
> distinguish between "internal" headers (that shouldn't be used outside a
> module) and "external" headers.
Unfortunately, the codebase isn't actually modular.
We have lot of places that include from other "modules" w/o any
In that case I'd suggest reordering the whole thing in a way that
these includes live under their own subdir (eg $module/include/...)
and have canonical directory names (just like as they were external
modules). Yes, that might be a lot to do, but we could do it in
In future, I'd like to have the individual modules as entirely
separate entities, which could live in their own packages.
On 7/22/2017 11:43 AM, Enrico Weigelt, metux IT consult wrote:
> In future, I'd like to have the individual modules as entirely
> separate entities, which could live in their own packages.
In general within the Thunderbird code, reorganization of module
management is an important issue. I've tended to look at the issue
mostly in the context of the Calendar code, as this (along with chat) is
where we are headed. They have a complex module management system, but
have discussed at some point moving to ES6 modules.
In the new maildev discussion list
I've suggested a project whereby we move the JS parts of all of
Thunderbird to ES6 modules. The general issue there is whether ES6
modules are sufficiently implemented within Gecko to make that move now,
or should we wait until later. The issue of when will be decided by
working code examples rather than by expressions of opinion, but I don't
think that anyone has said that, in the long run, we should do anything
except ES6 modules.