RFC: cleanup include directives

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

RFC: cleanup include directives

Enrico Weigelt, metux IT consult
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"

now:

#include <dom/media/gmp/GMPServiceChild.h>


--mtx
_______________________________________________
dev-apps-thunderbird mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-thunderbird
Reply | Threaded
Open this post in threaded view
|

Re: RFC: cleanup include directives

Enrico Weigelt, metux IT consult
On 21.07.2017 17:20, Enrico Weigelt, metux IT consult wrote:

<snip>

Just seen: we actually *do* have such includes already, eg:

#include "mozilla/dom/HTMLVideoElement.h"


So, should all include site be changed to the same style ?


--mtx

_______________________________________________
dev-apps-thunderbird mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-thunderbird
Reply | Threaded
Open this post in threaded view
|

Re: RFC: cleanup include directives

R Kent James
In reply to this post by Enrico Weigelt, metux IT consult
On 7/21/2017 10:20 AM, Enrico Weigelt, metux IT consult wrote:

> Eg. instead of
>
> #include "GMPService.h"
>
> now:
>
> #include <dom/media/gmp/GMPServiceChild.h>
>

All of the references to GMPService.h are in the mozilla directories,
which we (Thunderbird) do not control. Perhaps you should be making this
request to the Firefox folks instead?

:rkent

_______________________________________________
dev-apps-thunderbird mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-thunderbird
Reply | Threaded
Open this post in threaded view
|

Re: RFC: cleanup include directives

Enrico Weigelt, metux IT consult
On 21.07.2017 22:05, R Kent James wrote:

> All of the references to GMPService.h are in the mozilla directories,
> which we (Thunderbird) do not control. Perhaps you should be making this
> request to the Firefox folks instead?

I doubt they wanna talk to me - banned from there since many years.
Don't recall the actual reason anymore, guess because my proposal to
drop the bundled and outdated 3rdparty libs ...


--mtx

_______________________________________________
dev-apps-thunderbird mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-thunderbird
Reply | Threaded
Open this post in threaded view
|

Re: RFC: cleanup include directives

Joshua Cranmer 🐧
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"
>
> now:
>
> #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.

--
Joshua Cranmer
Thunderbird and DXR developer
Source code archæologist

_______________________________________________
dev-apps-thunderbird mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-thunderbird
Reply | Threaded
Open this post in threaded view
|

Re: RFC: cleanup include directives

Enrico Weigelt, metux IT consult
On 22.07.2017 16:54, Joshua Cranmer 🐧 wrote:

Hi,

> 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
pathname.

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
smaller steps.

In future, I'd like to have the individual modules as entirely
separate entities, which could live in their own packages.


--mtx

_______________________________________________
dev-apps-thunderbird mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-thunderbird
Reply | Threaded
Open this post in threaded view
|

Re: RFC: cleanup include directives

R Kent James
In reply to this post by Joshua Cranmer 🐧
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
an example of issues within a mostly JavaScript environment, which 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
(http://lists.thunderbird.net/mailman/listinfo/maildev_lists.thunderbird.net)
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.

:rkent
_______________________________________________
dev-apps-thunderbird mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-thunderbird