Build bustage. I refreshed C-C source tree about half an hour aog, and during make -f client.mk, I noticed the following failure. --- begin quote --- Reticulating splines... Traceback (most recent call last): File "./config.status", line 1010, in <module> config_status(**args) File "/REF-COMM-CENTRAL/comm-central/mozilla/python/mozbuild/mozbuild/config_status.py", line 149, in config_status summary = the_backend.consume(definitions) File "/REF-COMM-CENTRAL/comm-central/mozilla/python/mozbuild/mozbuild/backend/base.py", line 200, in consume self.consume_finished() File "/REF-COMM-CENTRAL/comm-central/mozilla/python/mozbuild/mozbuild/backend/recursivemake.py", line 755, in consume_finished self._check_blacklisted_variables(makefile_in, content) File "/REF-COMM-CENTRAL/comm-central/mozilla/python/mozbuild/mozbuild/backend/recursivemake.py", line 698, in _check_blacklisted_variables 'only be defined in moz.build files.' % (x, makefile_in)) Exception: Variable SHARED_LIBRARY_LIBS is defined in /REF-COMM-CENTRAL/comm-central/mailnews/import/build/Makefile.in. It should only be defined in moz.build files. *** Fix above errors and then restart with\ "make -f client.mk build" /REF-COMM-CENTRAL/comm-central/client.mk:361: recipe for target 'configure' failed --- end quote --- The message printed says all: Exception: Variable SHARED_LIBRARY_LIBS is defined in /REF-COMM-CENTRAL/comm-central/mailnews/import/build/Makefile.in. It should only be defined in moz.build files. So it seems that there is now a blacklist of variables which should not be tinkered with in Makefile.in. Observation: This variable check is fairly new. It is done in recursivemake.py: http://mxr.mozilla.org/comm-central/source/mozilla/python/mozbuild/mozbuild/backend/recursivemake.py#694 and it is introduced on March 27 into M-C. http://hg.mozilla.org/mozilla-central/rev/7f73bbf6df76 So, it is biting us now. I wonder if simply commenting out the offencing line in Makefile.in completes build successfully. I just checked and noticed the same problems on tryserver since Friday, too. Interesting Bug?: The code for checking the blacklisted variables seems to have an incorrect regular expression. 694 def _check_blacklisted_variables(self, makefile_in, makefile_content): 695 for x in MOZBUILD_VARIABLES: 696 if re.search(r'[^#]\b%s\s*[:?+]?=' % x, makefile_content, re.M): 697 raise Exception('Variable %s is defined in %s. It should ' 698 'only be defined in moz.build files.' % (x, makefile_in)) When I simply added "#" to the beginning of Makefile.in it still complained that there is a variable! I had to change the line in Makefile.in as follows before it stopped complaining: # ifdef MOZ_INCOMPLETE_EXTERNAL_LINKAGE # sHARED_lIBRARY_lIBS = ../../base/util/$(LIB_PREFIX)msgbsutl_s.$(LIB_SUFFIX) # endif Incorrect RE: I think the following is incorrect. re.search(r'[^#]\b%s\s*[:?+]?=' % x, makefile_content, re.M): I think if we want to include the search for the assignment to variable only before a comment is seen on the line ('#' introduces a comment) is something like this. ^[^#]*\b%s\s*[:?+]?= The current incorrect RE is not anchored at the beginning of line, and so the match started on "S" as shown in the lines below. # SHARED_LIBRARY_LIBS = ../../base xxooooooooooooooooooooo (xx are ignored and ooo...ooo matches the pattern. With the corrected RE, the match MUST start at the beginning of the line and '#' first seen breaks the match and thus the line will be ignored. So there are two issues. Can I simply comment out the library setting in Makefile.in? Also, RE in recursivemake.py needs to be fixed. TIA
I filed Bug 1153566 - Incorrect regular expression in _check_blacklisted_variables (recursivemake.py) for the incorrect regular expression issue. Hmm, just wanting to use a rock solid mail client (tm) is a long way to go...
> Can I simply comment out the library setting in Makefile.in? It seems so. I could build C-C TB which runs mozmill test just fine (with known persistent bugs, that is). TIA
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1153187
You need to log in before you can comment on or make changes to this bug.