On 2016年02月05日 00:49, ISHIKAWA,chiaki wrote:
> On 2016/02/04 0:19, ISHIKAWA,chiaki wrote:
>> Hi,
>>
>> Starting about 12 hours ago, I refreshed my source and got hit with
>> another build bustage locally.
>>
>> Namely, some header files in M-C part of the tree cannot be found during
>> compilation.
>>
>> I thought it was a temporary fluke. But, no, it is permanent. Although I
>> refreshed my tree about an hour ago, the problem still persists.
>>
>> I took a close look and found that header files below
>> ${MOZ_SRC}/mozilla/dom/base
>>
>> where MOZ_SRC is the top-level of my local C-C TB tree, are not found
>> during compilation.
>>
>> Checking the compiler command line, I found that the -I specification that
>> is supposed to point to
>> that directory is incorrect.
>>
>> After configure, it comes out as
>> -I ${MOZ_SRC}/dom/base
>>
>> without "mozilla/" part, thus the compiler could not find the header files
>> under mozilla/dom/base.
>>
>> Have anyone seen this?
>>
>> I have no idea about where to look except I vaguely recall that there has
>> been incorrect directory path specification before. But in that case, I
>> recall that the variable for the new build/configure mechanism got it all
>> wrong and every include path became incorrect (?)
>> In this case, I found the errors seemed to occur only for the header files
>> under mozilla/dom/base.
>>
>> TIA
>>
>> CI
>
> (I am adding dev-builds mailing list in the hompe that someone there may
> notice a symptom of known issue.)
>
>
> I investigated a little further and noticed that
>
> /dom/base was specified in the LOCAL_INCLUDES variable
> in respective directory where the problem ocucrred.
>
> So just as experiment, I changed /dom/base into a relative form such as
> ../../dom/base
> ../../../dom/base
> ../../../../dom/base
> according to the depth of the directory where moz.build is located.
>
>
> Voila!
>
> The compilation proceeded!?
>
> But I am really puzzled.
> Only the header files under dom/base are affected.
>
> This problem did not occur Jan 31 (and Feb 1 I think).
> It certainly did not occur before that.
>
> Only yesterday after refreshing the source, I noticed this problem.
> I looked at the mercurial logs of M-C portion of the tree, but could not find
> an entry that stood out (I am not familiar with build system and so
> I may have missed a crucial patch, etc. Also, there is a blanket log that
> says it would include all the patches in mozilla-incoming.)
>
> BTW, funny, it seems that LOCAL_INCLUDES seems to expect a SORTED list of
> values when a value is appended to it,
> and so I had to move the relative pathnames to the front of the list
> where there are multiple directories specified in LOCAL_INCLUDES: but
> I am afraid there may be an issue of improper ordering of
> include directories if we are forced to use lexicographically sorted include
> list paths. We may have a couple of header files with the SAME name and
> may want to include a particular one by specifying the include directory
> path for that include file. A case in point is discussed below [1])
>
> I was so puzzled and I looked into bugzilla and searched for
> |LOCAL_INCLUDES|, but
> only found an entry which generally discusses the header file inclusion issue.
>
> I wonder why possibly I am the only person on the earth who see this
> problem under local Linux development environment(?).
>
> I am using Debian GNU/Linux 64-bit.
>
> I had to disable a few features such as gstreams, etc. (gstream under Debian
> GNU/Linux is old and does not meet the version requirement of mozilla
> software.)
>
> But otherwise, I don't see a problem with my mozconfig.
> Like I mentioned, the build worked like a charm until Feb 1st.
>
> Any tips/hints regarding this issue will be appreciated.
> Should I file a bug ?
>
> [1] Case in point.
> mozilla/accessible/generic/HyperTextAccessible.cpp
> includes "TreeWalker.h".
>
> There are two TreeWalker.h in the source tree:
> mozilla/accessible/base/TreeWalker.h
> mozilla/dom/base/TreeWalker.h
>
> HyperTextAccessible.cpp needs to include the version under accessible/base,
> not
> under mozilla/dom/base. (If the latter is included, compiler complains about
> type mismatch.)
>
> So to meet the requirement that the value added to LOCAL_INCLUDES must be a
> sorted list and that ../../dom/base does not come before accessible/base in
> this particular case, I had to split the list into two as below.
>
> LOCAL_INCLUDES += [
> '/accessible/base',
> '/accessible/html',
> '/accessible/ipc',
> '/accessible/xpcom',
> '/accessible/xul',
> '/layout/generic',
> '/layout/xul',
> ]
>
> # I need to add /dom/base, but this has to be specified as relative
> # for some reason, and has to come AFTER the others.
> # Because of the requirement that a list must be sorted, I have to
> # separate the addition of dom/base in another assignment that comes
> # after the above (!)
> LOCAL_INCLUDES += ['../../dom/base' ]
>
>
> PS: But again, I am curious why this bustage?
> Only headers below dom/base seem to be affected.
>
The closest bug I can think of and found is the following one.
Bug 1222591 - nsMsgUtils.cpp:52:10: fatal error: 'nsProtocolProxyService.h'
file not found
But in that case, the header was not during the compilation of source files
in C-C portion of the tree.
This time, the compilation failes since the compiler can not find the
headers during the compilation of
the files in M-C portion of the tree. Strange...
TIA
_______________________________________________
dev-builds mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-builds
