make gbuildtojson and make xx-ide-integration problems.

classic Classic list List threaded Threaded
24 messages Options
Next » 12
jan iversen jan iversen
Reply | Threaded
Open this post in threaded view
|

make gbuildtojson and make xx-ide-integration problems.

(RESENDING WITHOUT ATTACHMENTS)

Hi Bjoern.

I continued to test gbuildtojson and xx-ide-integration, but have encountered a couple of problems, where I am stuck and need help (or at least a hint where to search).

My setup is Sierra (osX) and I have no problems with a full build. I have tried to reduce the build as much as possible (see attached autopen.input). I check with a patched post_GbuildToJson.mk (attached) based on your recommendations.

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.

1) gbuildtojson:

Jans-iMac:work jani$ make clean
rm -fr /Volumes/LIBREOFFICE/play/work/test-install
rm -fr /Volumes/LIBREOFFICE/play/work/instdir
rm -fr /Volumes/LIBREOFFICE/play/work/workdir
Jans-iMac:work jani$ make gbuildtojson
make -j 8 -rs -f /Volumes/LIBREOFFICE/play/core/Makefile.gbuild gbuildtojson
ld: warning: directory not found for option '-L/Volumes/LIBREOFFICE/play/work/workdir/LinkTarget/StaticLibrary'
ld: warning: directory not found for option '-L/Volumes/LIBREOFFICE/play/work/workdir/LinkTarget/Library'
ld: warning: directory not found for option '-L/Volumes/LIBREOFFICE/play/work/instdir/LibreOfficeDev.app/Contents/Frameworks'
ld: warning: directory not found for option '-L/Volumes/LIBREOFFICE/play/work/instdir/LibreOfficeDev.app/Contents/Frameworks'
ld: warning: directory not found for option '-L/Volumes/LIBREOFFICE/play/work/workdir/LinkTarget/Library'
Jans-iMac:work jani$ make gbuildtojson
make -j 8 -rs -f /Volumes/LIBREOFFICE/play/core/Makefile.gbuild gbuildtojson
Jans-iMac:work jani$ 

Remark, the ld error only comes first time, so maybe it is a sequence problem ? see attachment make_d_gbuildtojson line 19443.

2) xx-ide-integration
I have test with Xcode and vim, same result (clearly because error occurs during startup.

 make vim-ide-integration
make -j 8 -rs -f /Volumes/LIBREOFFICE/play/core/Makefile.gbuild gbuildtojson
cd /Volumes/LIBREOFFICE/play/core && /Volumes/LIBREOFFICE/play/core/bin/gbuild-to-ide --ide vim --make make
'NoneType' object has no attribute 'group'
Traceback (most recent call last):
  File "/Volumes/LIBREOFFICE/play/core/bin/gbuild-to-ide", line 1656, in <module>
    gbuildparser = GbuildParser(args.makecmd).parse()
  File "/Volumes/LIBREOFFICE/play/core/bin/gbuild-to-ide", line 185, in parse
    lib = self.__lib_from_json(json.load(f))
  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

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


The first problem, seems not to have a serious effect (the json files are identical between first and second run), but the second one means no ide-integration

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.

rgds
jan I.













_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
Markus Mohrhard Markus Mohrhard
Reply | Threaded
Open this post in threaded view
|

Re: make gbuildtojson and make xx-ide-integration problems.

Hey Jan,

On Wed, Dec 14, 2016 at 1:32 PM, Jan Iversen <[hidden email]> wrote:
(RESENDING WITHOUT ATTACHMENTS)



2) xx-ide-integration
I have test with Xcode and vim, same result (clearly because error occurs during startup.

 make vim-ide-integration
make -j 8 -rs -f /Volumes/LIBREOFFICE/play/core/Makefile.gbuild gbuildtojson
cd /Volumes/LIBREOFFICE/play/core && /Volumes/LIBREOFFICE/play/core/bin/gbuild-to-ide --ide vim --make make
'NoneType' object has no attribute 'group'
Traceback (most recent call last):
  File "/Volumes/LIBREOFFICE/play/core/bin/gbuild-to-ide", line 1656, in <module>
    gbuildparser = GbuildParser(args.makecmd).parse()
  File "/Volumes/LIBREOFFICE/play/core/bin/gbuild-to-ide", line 185, in parse
    lib = self.__lib_from_json(json.load(f))
  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

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


The first problem, seems not to have a serious effect (the json files are identical between first and second run), but the second one means no ide-integration

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.

rgds
jan I.





So this is related to my patch bringing the unit tests into gbuildtojson. Sadly I can not reproduce it but already had another person with the same problem and forwarded my analysis to Björn. Somehow the makefiles info is mixed up at some point but I was unable to figure out when and why. IF you need a quick way to continue your work you can revert https://cgit.freedesktop.org/libreoffice/core/commit/?id=ee8057caaa26dcddbf80b1e0a2f02d250089d1e3 which should "fix" the problem.

Obviously a correct fix would be helpful and having the tests in gbuildtojson is a useful addition.

Regards,
Markus

_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
Bjoern Michaelsen Bjoern Michaelsen
Reply | Threaded
Open this post in threaded view
|

Re: make gbuildtojson and make xx-ide-integration problems.

In reply to this post by jan iversen
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
_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
Michael Stahl-2 Michael Stahl-2
Reply | Threaded
Open this post in threaded view
|

Re: make gbuildtojson and make xx-ide-integration problems.

On 12/14/2016 04:23 PM, Bjoern Michaelsen wrote:
> On Wed, Dec 14, 2016 at 01:29:28PM +0100, Jan Iversen wrote:

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

the problem with that is that

> define gb_Module_add_check_target
> $(if $(filter CppunitTest_%,$(2)),$(call gb_Module__add_check_target_impl,$(1),$(2),$$(gb_Module_CURRENTTARGET)))
> endef

... expects only CppunitTest_% and does nothing with a Library_% being
added, and Module_sc.mk has:

> $(eval $(call gb_Module_add_check_targets,sc,\
> Library_scqahelper \
> $(if $(and $(filter $(COM),MSC),$(MERGELIBS)),, \
> CppunitTest_sc_ucalc) \
> CppunitTest_sc_core \
> ))


_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
Matúš Kukan Matúš Kukan
Reply | Threaded
Open this post in threaded view
|

Re: make gbuildtojson and make xx-ide-integration problems.

In reply to this post by jan iversen
On 14 December 2016 at 13:32, Jan Iversen <[hidden email]> wrote:
> 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).

/me wonders why I don't have any workdir/GbuildToJson/Library/*scqahelper*

Anyway, I've also touched xcode generation in
https://gerrit.libreoffice.org/#/c/32027/
I think there was the same problem as with different visual studio
project files having the same name.
..just to know

HTH,

Matus
_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
Alex Thurgood Alex Thurgood
Reply | Threaded
Open this post in threaded view
|

Re: make gbuildtojson and make xx-ide-integration problems.

Le 15/12/2016 à 08:56, Matúš Kukan a écrit :

FWIW, the xcode-ide-integration still fails for me for what appears to
be a lack of a python3 environment - OSX 10.12 default is python2.7,
which is what make finds, so I'm assuming that something in the
gbuildtojson script requires python3 ?

Alex




_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
jan iversen jan iversen
Reply | Threaded
Open this post in threaded view
|

Re: make gbuildtojson and make xx-ide-integration problems.


> FWIW, the xcode-ide-integration still fails for me for what appears to
> be a lack of a python3 environment - OSX 10.12 default is python2.7,
> which is what make finds, so I'm assuming that something in the
> gbuildtojson script requires python3 ?
two different things.

try to run
make gbuildtojson
that does not require python3.

make Xcode-ide-integration (and all other ones still fails with python claiming that a .group statement does not work.

If your make does not fail with a python backtrace, then you have another problem, like missing python3.

rgds
jan I.

_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
Alex Thurgood Alex Thurgood
Reply | Threaded
Open this post in threaded view
|

Re: make gbuildtojson and make xx-ide-integration problems.

Le 15/12/2016 à 11:50, Jan Iversen a écrit :
>

The error message is :


env: python3: No such file or directory

Alex

_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
jan iversen jan iversen
Reply | Threaded
Open this post in threaded view
|

Re: make gbuildtojson and make xx-ide-integration problems.


> env: python3: No such file or directory
As is says no python3, that is needed for make foo-ide-integration

but even if you install python3, you will (at least on sierra) still have a problem, because of a json file being generated with wrong information.

rgds
jan I

_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
Michael Stahl-2 Michael Stahl-2
Reply | Threaded
Open this post in threaded view
|

Re: make gbuildtojson and make xx-ide-integration problems.

On 12/15/2016 12:02 PM, Jan Iversen wrote:
>
>> env: python3: No such file or directory
> As is says no python3, that is needed for make foo-ide-integration
>
> but even if you install python3, you will (at least on sierra) still have a problem, because of a json file being generated with wrong information.

but we build python3 anyway, why don't we just use that to run the
bin/gbuild-to-ide script, then it'll run even on macOS?


_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
Alex Thurgood Alex Thurgood
Reply | Threaded
Open this post in threaded view
|

Re: make gbuildtojson and make xx-ide-integration problems.

In reply to this post by jan iversen
Le 15/12/2016 à 11:50, Jan Iversen a écrit :
>

>
> If your make does not fail with a python backtrace, then you have another problem, like missing python3.
>

Did I misunderstand something, as I don't recall python3 becoming a
requirement for building LO ?
The default python framework on OSX 10.12.1 is python2.7 and this is
what appears in the shell.

The gbuildtojson script looks in workdir/GeneratedPackage directory for
python3 but this isn't built by default in an OSX build because a
top-level make finds python2.7 :

checking for a Python interpreter with version >= 2.6...python
checking for python version...2.7
checking for python platform...Darwin
...
checking which Python to use for Pyuno...
checking for a python interpreter with version >= 3.3...none




Alex



_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
jan iversen jan iversen
Reply | Threaded
Open this post in threaded view
|

Re: make gbuildtojson and make xx-ide-integration problems.

In reply to this post by Michael Stahl-2

but we build python3 anyway, why don't we just use that to run the
bin/gbuild-to-ide script, then it'll run even on macOS?
I can only look at my configuration, where tml_ helped me, and I needed to have --enable-python=fully-internal in autogen.input to make a full build work.

Since foo-ide-integration and gbuildtojson runs with a build (directly after a make clean), that will not work.

Maybe there are other ways to get python3 working with our build, but I had a mess of 2.7 header files (from apple) and 3.0 header files from an official python3 installation, and the solution seemed to be the above option.

rgds
jan I.


_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
Alex Thurgood Alex Thurgood
Reply | Threaded
Open this post in threaded view
|

Re: make gbuildtojson and make xx-ide-integration problems.

In reply to this post by Alex Thurgood
Le 15/12/2016 à 12:11, Alexander Thurgood a écrit :

And surely the whole aim of the foo-ide-integration thing is to allow
the default to be built from within the target IDE and not to require
setting ENVs for frameworks that are not the default ?



Alex

_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
jan iversen jan iversen
Reply | Threaded
Open this post in threaded view
|

Re: make gbuildtojson and make xx-ide-integration problems.


> On 15 Dec 2016, at 12:32, Alexander Thurgood <[hidden email]> wrote:
>
> Le 15/12/2016 à 12:11, Alexander Thurgood a écrit :
>
> And surely the whole aim of the foo-ide-integration thing is to allow
> the default to be built from within the target IDE and not to require
> setting ENVs for frameworks that are not the default ?
In my mind the target is actually to supply the solutions, and run “make whatever” on our tinderboxes to do the generation.

But this is still something being discussed, right now, we are at the level of getting it to work first.

rgds
jan I.

>
>
>
> Alex
>
> _______________________________________________
> LibreOffice mailing list
> [hidden email]
> https://lists.freedesktop.org/mailman/listinfo/libreoffice

_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
Bjoern Michaelsen Bjoern Michaelsen
Reply | Threaded
Open this post in threaded view
|

Re: make gbuildtojson and make xx-ide-integration problems.

In reply to this post by Michael Stahl-2
Hi,

On Thu, Dec 15, 2016 at 12:05:38PM +0100, Michael Stahl wrote:
> but we build python3 anyway, why don't we just use that to run the
> bin/gbuild-to-ide script, then it'll run even on macOS?

right, doing python2 (only) scripts these days is foolish as it is phasing out.
FWIW, this has nothing to do with what configure finds, but with:

 #! /usr/bin/env python3

in the first line of gbuild-to-ide looking for whatever python3 interpreter is
on the system. I would oppose porting gbuild-to-ide back to python2 -- for the
reasons noted above. I would not oppose to make gbuild-to-ide work with python2
too, if someone is enthusiastic about it.

As for using the python3 that LibreOffice bundles anyway: That is nice ... in
theory. In practice, the bootstrapping makes this a bit tricky: gbuild-to-ide
is supposed to work before a full build is there. So we either have to:

- let go of that requirement on OSX where getting python3 is a hassle
  (its no issue on Linux, neither on Windows as long as we need cygwin anyway)
- use something different than Python3 for bootstrapping the env
  (then again: What? Python is probably the bestsuited tool crossplatform tool
  available for this task -- even with the Python2/3 mess).
- sprinkle some fairy dust on OSX to make them ship an Python that was releases
  8 years ago ...

Best,

Bjoern
_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
jan iversen jan iversen
Reply | Threaded
Open this post in threaded view
|

Re: make gbuildtojson and make xx-ide-integration problems.

> - let go of that requirement on OSX where getting python3 is a hassle
>  (its no issue on Linux, neither on Windows as long as we need cygwin anyway)
> - use something different than Python3 for bootstrapping the env
>  (then again: What? Python is probably the bestsuited tool crossplatform tool
>  available for this task -- even with the Python2/3 mess).
> - sprinkle some fairy dust on OSX to make them ship an Python that was releases
>  8 years ago …

since you have already made the ball rolling by making gbuildtojson in C++ the logical consequence would be to port the script to C++.

rgds
jan I.


_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
Bjoern Michaelsen Bjoern Michaelsen
Reply | Threaded
Open this post in threaded view
|

Re: make gbuildtojson and make xx-ide-integration problems.

Hi,

On Thu, Dec 15, 2016 at 01:02:05PM +0100, Jan Iversen wrote:
> since you have already made the ball rolling by making gbuildtojson in C++
> the logical consequence would be to port the script to C++.

My fear with that was it (using C++ instead of Python) would discourage people
to contribute for other IDEs. But now that we have at least a wireframe
implementation for most popular IDEs going straight to C++ might indeed be our
best option[1] bootstrapping-wise. Although parsing JSON in C++ is rather ...
meh, but we certainly dont want an external dependency for that.

Probably needs an iterative approach: first parse the JSON stuff in some C++
objects and create output for the first IDE. Other IDEs move over from Python
to C++ one by one later.

Best,

Bjoern

[1] tsss, the irony of that.
_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
Markus Mohrhard Markus Mohrhard
Reply | Threaded
Open this post in threaded view
|

Re: make gbuildtojson and make xx-ide-integration problems.

Hey,

so with the experience of writing one of the ide integrations and helping people especially during the night some comments.

On Thu, Dec 15, 2016 at 1:33 PM, Bjoern Michaelsen <[hidden email]> wrote:
Hi,

On Thu, Dec 15, 2016 at 01:02:05PM +0100, Jan Iversen wrote:
> since you have already made the ball rolling by making gbuildtojson in C++
> the logical consequence would be to port the script to C++.

My fear with that was it (using C++ instead of Python) would discourage people
to contribute for other IDEs. But now that we have at least a wireframe
implementation for most popular IDEs going straight to C++ might indeed be our
best option[1] bootstrapping-wise. Although parsing JSON in C++ is rather ...
meh, but we certainly dont want an external dependency for that.

Probably needs an iterative approach: first parse the JSON stuff in some C++
objects and create output for the first IDE. Other IDEs move over from Python
to C++ one by one later.



I'm not really sure if switching to C++ will really help us long term. It might solve the python3 problem on OSX short term but would make hacking the IDE generator quite painful. Actually at least I don't see huge problem with letting the script depend on the python that we use for the build, whether internal or external, and therefore just build the python on OSX when we run the script. At least for the case that we pre-generate IDE solutions (which is what I read to make it apparently possible for really everyone to open a LibreOffice source file) I think it would not be an issue. And for anyone who actually still would use the command line to build LibreOffice it should make even less of a difference.


Also a few comments for the general discussion.

In general my experience from mentoring people and helping out during the European night is that at least currently our problem is not really the missing IDE integration. At least from what I can see currently the two big problems that we have are some unreliable tests, e.g. the OpenCL ones, and the brittle setup on windows. So I think focusing on these two issues for now would help new people much more. Additionally I don't believe that we will ever be able to cover every single part of the LibreOffice build process in an IDE so it might make more sense to use the IDE integration for the normal C++ source file hacking and leave the rest to make, so basically going with the old 80/20 rule. If the build would be less brittle, mostly on windows, calling make once should not be such a big problem. Actually at least I would most likely not want to mentor a person that considers calling make once in a command line a reason not to contribute to the project.
Besides that I see a problem with having a second way of building LibreOffice especially from the mentoring perspective. We already have the huge problem that experienced developers often don't use the setup that we suggest to new developers. Increasing the difference between these groups would make the mentoring even more complicated. From this perspective a reliable and well tested IDE integration that supports the common task, hacking the source files with auto completion and maybe debugging of LibreOffice and tests, without the additional complexity of a complete build in the IDE seems like a less painful solution. It surely would be easier to maintain and support people using such an IDE integration.


Regards,
Markus





_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
Michael Stahl-2 Michael Stahl-2
Reply | Threaded
Open this post in threaded view
|

Re: make gbuildtojson and make xx-ide-integration problems.

On 12/15/2016 02:58 PM, Markus Mohrhard wrote:

> On Thu, Dec 15, 2016 at 1:33 PM, Bjoern Michaelsen
> <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     Hi,
>
>     On Thu, Dec 15, 2016 at 01:02:05PM +0100, Jan Iversen wrote:
>     > since you have already made the ball rolling by making gbuildtojson in C++
>     > the logical consequence would be to port the script to C++.
>
>     My fear with that was it (using C++ instead of Python) would
>     discourage people
>     to contribute for other IDEs. But now that we have at least a wireframe
>     implementation for most popular IDEs going straight to C++ might
>     indeed be our
>     best option[1] bootstrapping-wise. Although parsing JSON in C++ is
>     rather ....
>     meh, but we certainly dont want an external dependency for that.
>
>     Probably needs an iterative approach: first parse the JSON stuff in
>     some C++
>     objects and create output for the first IDE. Other IDEs move over
>     from Python
>     to C++ one by one later.
>
>
>
> I'm not really sure if switching to C++ will really help us long term.
> It might solve the python3 problem on OSX short term but would make
> hacking the IDE generator quite painful. Actually at least I don't see
> huge problem with letting the script depend on the python that we use
> for the build, whether internal or external, and therefore just build
> the python on OSX when we run the script. At least for the case that we
> pre-generate IDE solutions (which is what I read to make it apparently
> possible for really everyone to open a LibreOffice source file) I think
> it would not be an issue.

i'm rather unconvinced of yet another c++ rewrite so here's my patch to
use the internal python3 on macOS:

https://gerrit.libreoffice.org/#/c/32047/



_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
Bjoern Michaelsen Bjoern Michaelsen
Reply | Threaded
Open this post in threaded view
|

Re: make gbuildtojson and make xx-ide-integration problems.

In reply to this post by Markus Mohrhard
Hi,

On Thu, Dec 15, 2016 at 02:58:29PM +0100, Markus Mohrhard wrote:
> At least from what I can see currently the two big problems that we have are
> some unreliable tests, e.g. the OpenCL ones, and the brittle setup on
> windows. So I think focusing on these two issues for now would help new
> people much more.

Agreed.

> Additionally I don't believe that we will ever be able to cover every single
> part of the LibreOffice build process in an IDE so it might make more sense
> to use the IDE integration for the normal C++ source file hacking and leave
> the rest to make, so basically going with the old 80/20 rule.

Yup.

> If the build would be less brittle, mostly on windows, calling make once
> should not be such a big problem. Actually at least I would most likely not
> want to mentor a person that considers calling make once in a command line a
> reason not to contribute to the project.

Yes, but also plumbing whatever build button there is in an IDE to call make is
trivial. The non-trivial part is with LibreOffice -- because of its size -- the
strategy of 'eh, lets just build everything all of the time' is somewhat more
painful than for trivial projects. While it is the safe default for newcomers,
regulars usually dont want to spent their time triggering full build everytime.
This problem (that we have all 'module build', 'full build', 'unitcheck',
'slowcheck', 'subsequentcheck' being useful and needed build scenarios) wont go
away by any tweaks in IDEs and or using any build system. There simply cant be
a one-size-fits-all button in the IDE for this.

> Increasing the difference between these groups would make the mentoring even
> more complicated. From this perspective a reliable and well tested IDE
> integration that supports the common task, hacking the source files with auto
> completion and maybe debugging of LibreOffice and tests, without the
> additional complexity of a complete build in the IDE seems like a less
> painful solution. It surely would be easier to maintain and support people
> using such an IDE integration.

Yes, and since, as you so eloquently pointed out, setup is still the most
tricky part of this -- at least on Windows -- I wonder if the solution is
possibly rather to double down on having properly preconfigured VMs with IDE,
debugging and code completion available and ready to spin up at a minutes
notice ...

Best,

Bjoern
_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
Next » 12