On 2013-11-17 7:53 PM, Jonas Sicking wrote:
On Sat, Nov 16, 2013 at 1:34 AM, Ms2ger <ms2...@gmail.com> wrote:
One issue I only thought of today: this means that Source2.cpp can use all
headers included into Source1.cpp–until enough files are added between
Source1 and Source2 that Source2 ends up in the next unified file. This
hasn't been much of an issue for autogenerated C++, but it seems like it
could be harder to get right with hand-written C++.
One way around it would be not to unify sources in automation. On one hand,
this could cause more bustage when changes that built locally turn out not
to have enough includes; on the other, it might be better than having to fix
up a dozen unrelated files whenever you add a new one.
This sounds like a huge problem to me.
There's also the problem that some header files, in particular on
windows, add macros which can wreck havoc in our cpp files.
This happened recently with our autogenerated C++ files where adding a
.webidl file pushed a .cpp file from going from one unified file to
the next. This .cpp file pulled in one of these windows headers. The
result was that now a whole new set of files were exposed to the
windows macros and some of them broke.
This was a huge headache and I know that one of the solutions that
were seriously considered was to rename the new .webidl file from
foopy.webidl to zzfoopy.webidl.
A much easier solution for non-webidl unified code is to move foopy.cpp
to SOURCES (instead of UNIFIED_SOURCES) and then fix things up later on
if needed.
Cheers,
Ehsan
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
