Date: prev next · Thread: first prev next last
2016 Archives by date, by thread · List index


Hi,

On Wed, Dec 14, 2016 at 01:29:28PM +0100, Jan Iversen wrote:
I have 2 problems. First problem when running “make gbuildtojson”. It seems
the linker is called in post_GbuildToJson.mk. In order to verify it I ran
“make -d gbuildtojson” (attached), where it can be seen the warning comes
directly after reading the makefile.

Yes, it seems some extra dependencies still exist, likely OSX specific. "make
-d gbuildtojson" is the right way to go about it, however doing that from the
toplevel creates a lot of output, makes it hard to see the trees in the forest.

Id suggest to try "make -d gbuildtojson" in the modules and find the smallest
one falling and then look at the output of that one (possibly commenting out
stuff in Module_foo.mk to corner the issue).

  File "/Volumes/LIBREOFFICE/play/core/bin/gbuild-to-ide", line 136, in __lib_from_json
    GbuildParser.libpattern.match(os.path.basename(json['MAKEFILE'])).group(1),
AttributeError: 'NoneType' object has no attribute 'group'
Makefile:413: recipe for target 'vim-ide-integration' failed
make: *** [vim-ide-integration] Error 1

This essentially means the GbuildParser.libpattern regexp from
/bin/gbuild-to-ide does not find what it expects, namely: Library_(.*)\.mk in
the MAKEFILE variable. Looking at the attached file
workdir/GbuildToJson/Library/libscqahelper.dylib it has:

 "MAKEFILE": "/Volumes/LIBREOFFICE/play/core/sc/CppunitTest_sc_ucalc.mk"

which is wrong. It should be:

 "MAKEFILE": "/Volumes/LIBREOFFICE/play/core/sc/Library_scqahelper.mk"

And using a Library_foo.mk regex on a CppunitTest_foo.mk ist doomed. The
MAKEFILE var is filled at
https://gerrit.libreoffice.org/gitweb?p=core.git;a=blob;f=solenv/gbuild/extensions/post_GbuildToJson.mk;h=c608e33c654677491a8d34df368d1e488934ba7c;hb=4e9dd6e1b79983db087790a50c811b8b14b65f8f#l57
by filling T_MAKEFILE in gb_Postprocess_register_target with the last read
makefile.

That works in general, but apparently not in this case -- I assume be
scqahelper is not shipped with the product and never registered in postprocess.
A solution would be to set the T_MAKEFILE var in the same way it was done for
CppunitTests, which arent registered in postprocess either. see:

 
https://gerrit.libreoffice.org/gitweb?p=core.git;a=commitdiff;h=ee8057caaa26dcddbf80b1e0a2f02d250089d1e3;hp=787d31a94510ca3de9ce582d7b7402dfca584b23

by moggi for reference.


I ran it in my debugger and the file in question is
'/workdir/GbuildToJson/Library/libscqahelper.dylib’ which has ‘“MAKEFILE":
"'/Volumes/LIBREOFFICE/play/core/sc/CppunitTest_sc_ucalc.mk’”’ (see
attachment GbuildToJson.tgz).

I first though the additional quotes were the issue, but those arent in the
attached file, thus assuming the above is a better explaination. Still curious
why you had the extra single quotes here?
 
 
I look forward to hear your advice, my intention is currently to keep
testing/correcting this until I have an acceptable solution on mac and
windows, then that can be used as base for the perl removal and busybox
integration.

For the second problem see above: its likely due to scqahelper not being
shipped in the product. The good fix would be to do the same as was done for
CppunitTests for Libraries and Executables to find T_MAKEFILE.
As an temporary hotfix until you have the proper fix, you could also make
bin/gbuild-to-ide just print a "warning: target foo has no proper makefile
defined -- skipping" and then ignore the troublesome (few) non-shipped libs for
now.

Best,

Bjoern

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.