Re: gbuildtojson

classic Classic list List threaded Threaded
15 messages Options
Bjoern Michaelsen Bjoern Michaelsen
Reply | Threaded
Open this post in threaded view
|

Re: gbuildtojson

Hi Jan,

On Mon, Dec 05, 2016 at 06:40:30PM +0100, Jan Iversen wrote:

> If you want I can put this on the dev mailing list as well, but I thought it
> better to keep the noise down.
>
> OSX Sierra, newest master, I do:
>
> make
> …. (to control it can build)
> make clean
> and then
> make gbuildtojson
>
> that gives me a strange error:
> make gbuildtojson
> make  -rs -f /Volumes/LIBREOFFICE/play/core/Makefile.gbuild gbuildtojson
> ld: warning: directory not found for option '-L/Volumes/LIBREOFFICE/play/testNoMake/workdir/LinkTarget/StaticLibrary'
> ld: warning: directory not found for option '-L/Volumes/LIBREOFFICE/play/testNoMake/workdir/LinkTarget/Library'
> ld: warning: directory not found for option '-L/Volumes/LIBREOFFICE/play/testNoMake/instdir/LibreOfficeDev.app/Contents/Frameworks'
> ld: warning: directory not found for option '-L/Volumes/LIBREOFFICE/play/testNoMake/instdir/LibreOfficeDev.app/Contents/Frameworks'
> ld: warning: directory not found for option '-L/Volumes/LIBREOFFICE/play/testNoMake/workdir/LinkTarget/Library'
> [OCX] jvmfwk/plugins/sunmajor/pluginlib/util_cocoa.mm
> [OCX] vcl/osx/a11yactionwrapper.mm
> In file included from /Volumes/LIBREOFFICE/play/core/vcl/osx/a11yactionwrapper.mm:21:
> In file included from /Volumes/LIBREOFFICE/play/core/vcl/inc/osx/salinst.h:33:
> In file included from /Volumes/LIBREOFFICE/play/core/vcl/inc/salinst.hxx:29:
> /Volumes/LIBREOFFICE/play/core/vcl/inc/displayconnectiondispatch.hxx:24:10: fatal error: 'com/sun/star/awt/XDisplayConnection.hpp' file not found
> #include <com/sun/star/awt/XDisplayConnection.hpp>
>          ^
> 1 error generated.
> /Volumes/LIBREOFFICE/play/core/solenv/gbuild/LinkTarget.mk:323: recipe for target '/Volumes/LIBREOFFICE/play/testNoMake/workdir/ObjCxxObject/vcl/osx/a11yactionwrapper.o' failed
> make[1]: *** [/Volumes/LIBREOFFICE/play/testNoMake/workdir/ObjCxxObject/vcl/osx/a11yactionwrapper.o] Error 1
> Makefile:266: recipe for target 'gbuildtojson' failed
> make: *** [gbuildtojson] Error 2
>
>
> It is as if it tries to compile something ??
>
> any advice/patch is appreciated.

seems like you need to disable compiling of ObjectiveC sources in
https://cgit.freedesktop.org/libreoffice/core/tree/solenv/gbuild/extensions/post_GbuildToJson.mk#n75
like it was done for C/C++/generated C/C++ (lines 75-78 and 94-101).

Likely you need something like:

 gb_LinkTarget_add_objcobject =
 gb_LinkTarget_add_objcxxobject =
 gb_Library_add_objcobject =
 gb_Library_add_objcxxobject =
 gb_Executable_add_objcobject =
 gb_Executable_add_objcxxobject =

added there, to keep this from failing on OSX. More sophistication might be
needed to export the info about Objective C/C++ files to json too, if that is
wanted for e.g. IDEs.

HTH,

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: gbuildtojson

Hi Bjoern

> seems like you need to disable compiling of ObjectiveC sources in
> https://cgit.freedesktop.org/libreoffice/core/tree/solenv/gbuild/extensions/post_GbuildToJson.mk#n75
> like it was done for C/C++/generated C/C++ (lines 75-78 and 94-101).
Thanks for a fast and vey useful reply.

I will try and make a patch tomorrow.

I am playing with gbuildtojson, to see if I can combine my ideas with yours....I lack (for now) one important information in your json files, and that is the dependency tree (make -d).

And yes objective c++ is also wanted like java and python, my goal is still to be able to load a solution in a IDE press build and its done.....I have solved modules like external as customer scripts.

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: gbuildtojson

Hi,

On Mon, Dec 05, 2016 at 08:14:30PM +0100, jan iversen wrote:
> my goal is still to be able to load a solution in a IDE press build and its done....


Hmmm? That is already possible in most of the gbuild-to-ide created solutions
as of now e.g. KdevelopIdeIntegration has 'Full Build -- Release' (which just
calls a global make), QtCreator has '9-Global build'. Indeed, for MSVS we
currently only generate targets per module, but a 'global build' build config
that does a top-level make should be trivial to add.

So what usecase are you aiming for? for which benefits which are not covered by
current solutions?

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: gbuildtojson



> Hmmm? That is already possible in most of the gbuild-to-ide created solutions
> as of now e.g. KdevelopIdeIntegration has 'Full Build -- Release' (which just
> calls a global make), QtCreator has '9-Global build'. Indeed, for MSVS we
> currently only generate targets per module, but a 'global build' build config
> that does a top-level make should be trivial to add.

well last time I tried it in windows java and python was not included. Also there was a lot of targets missing.

>
> So what usecase are you aiming for? for which benefits which are not covered by
> current solutions?
The simple use case, of being able to develop/build/debug within the IDE....especially debugging is important. setting breakpoints on the lines and viewing variables is what students learn todo.

Students want to do all development within the IDE, and I do not see why it should be impossible.

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: gbuildtojson

Hi,

On Mon, Dec 05, 2016 at 10:52:36PM +0100, jan iversen wrote:
> well last time I tried it in windows java and python was not included. Also
> there was a lot of targets missing.

Well, Python/Java are ~7% of LOC in LibreOffice core repo, and less then 2%(?)
of the shipped core product. The latter is thankfully sinking: The only place
were new non-C++ code is acceptable in the core repo is non-shipped testcode
(for shipped C++ code).

> The simple use case, of being able to develop/build/debug within the
> IDE....especially debugging is important. setting breakpoints on the lines
> and viewing variables is what students learn todo.

Thats already possible with existing IDE integrations.

> Students want to do all development within the IDE, and I do not see why it should be impossible.

"All development within the IDE" (including breakpoints and debugging) is already
the status quo.

So:
1/ LibreOffice core development (in C++) as described above is already covered
   by existing solutions.
2/ Python/Java non-core development support is somewhat lacking. But the
   solution there is not fiddling around with gbuild -- rather rewriting the
   LibreOffice SDK (http://api.libreoffice.org/docs/install.html) and make it
   trivial to install and use. C++ isnt a priority for that[1].
3/ Mixing these two is ill-advised -- and that has little to do with the build
   system. As said, the only place for non-C++ code in the core repo is for
   testcode testing C++ implementations. If you are debugging a C++/Python or
   C++/Java mix talking over an UNO bridge, setting breakpoints in an IDE will
   be the least of your problems[2].

Also note for 1/ we really, really only want _one_ build system. The _current_
plethora of build configurations and platforms is already an major factor in
slowing down development and we really, really dont want to want to add more
"diversity" or TIMTOWTDI there[3].

So again: What usecase that isnt covered by existing solutions are you looking
for?

Best,

Bjoern


[1] Note that for this (non-core development), my talk at FOSDEM provided good
    hints and a proof of concept on how to get LibreOffice extension
    development going with PyDev, including breakpoints etc.:
    http://people.canonical.com/~bjoern/presentations/snakes.odp
    But again: This has nothing to do with core development!

[2] From a TDD perspective, if your test coverage is fine-grained enough, you
    will never need a debugger, because your tests makes obvious where your code
    is wrong, without stepping through things interactively or breakpoints. For
    me, the is the only reason to allow new non-C++ testcode in core. A test
    that still needs breakpoints and interactive stepping, you are indeed better
    served with C++ tests.

[3] One day the day may come that we want/need to replace gbuild with something
    different. Once that day is there, we will have to migrate to whatever
    replaces it as swiftly as possible (which will be, given the size of the
    project, still be very slow, even though gbuildtojson and the cleanup that
    happened when we introduced gbuild will make it a lot easier than it was to
    get away from dmake). But before a/ there is a clear need to kill gbuild
    and b/ there is a build system that promises to cover the whole core build,
    this is not an option. In other words: A new build system must be able to
    completely kill and replace gbuild, and be worth the effort.

    Gbuild could pull off that trick -- not because it was such a masterpiece of
    engineering -- it isnt. It was only worth it because dmake was such a pain.

    That said, GNU make is a small -- and by now native -- dependency on all
    platforms. Cygwin as a dependency on Windows is a much bigger risk and
    painpoint. I suspect, if anything, that will be killed first.
_______________________________________________
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: gbuildtojson


Well, Python/Java are ~7% of LOC in LibreOffice core repo, and less then 2%(?)
of the shipped core product.

But if I want to make an executable within the IDE, or debug e.g. some of the unit test I still need it.

One of the hard points for new people is actually to be able to debug unit tests.


The simple use case, of being able to develop/build/debug within the
IDE....especially debugging is important. setting breakpoints on the lines
and viewing variables is what students learn todo.

Thats already possible with existing IDE integrations.
At least not in the Xcode integration.

for a couple of reasons (which might apply to windows as well, will test that later):
- the debugger cannot run, it has not main executable.
- make and Xcode puts objects in different places.
- Also it is important to see the relationship between modules (especially when searching for symbols).

Students want to do all development within the IDE, and I do not see why it should be impossible.

"All development within the IDE" (including breakpoints and debugging) is already
the status quo.

I might be doing something wrong, but I have until and including today, not being able to 1/ set a breakpoint 2/ press debug 3/ stop at the breakpoint, neither in windows nor in Xcode.


1/ LibreOffice core development (in C++) as described above is already covered
  by existing solutions.

See above, right now the Xcode-ide-integration has another problem:
Jans-iMac:work jani$ make xcode-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 xcode --make make
Traceback (most recent call last):
  File "/Volumes/LIBREOFFICE/play/core/bin/gbuild-to-ide", line 1651, in <module>
    gbuildparser = GbuildParser(args.makecmd).parse()
  File "/Volumes/LIBREOFFICE/play/core/bin/gbuild-to-ide", line 180, in parse
    lib = self.__lib_from_json(json.load(f))
  File "/Volumes/LIBREOFFICE/play/core/bin/gbuild-to-ide", line 131, 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 'xcode-ide-integration' failed
make: *** [xcode-ide-integration] Error 1

which I will investigate and patch.

2/ Python/Java non-core development support is somewhat lacking. But the
  solution there is not fiddling around with gbuild -- rather rewriting the
  LibreOffice SDK (http://api.libreoffice.org/docs/install.html) and make it
  trivial to install and use. C++ isnt a priority for that[1].
We should not be fiddling with the gbuild system, I never suggested that.

But you forget that we have many unit tests written in Java and python, which we ask new people to debug when they have problems.

Also note for 1/ we really, really only want _one_ build system. The _current_
plethora of build configurations and platforms is already an major factor in
slowing down development and we really, really dont want to want to add more
"diversity" or TIMTOWTDI there[3].
I politely disagree here. we have 1 master build system and that is gbuild, but I cannot see anything hindering, that we use the ONE build system, to generate e.g. a IDE build system.

I never suggested, and will not suggest to have a second build system as master.

So again: What usecase that isnt covered by existing solutions are you looking
for?
Simply put, to be able to debug in the IDE, make simple changes, run again and see the effect, which I still have not been able to do.

rgds
jan i.


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

Re: gbuildtojson

Hello!

On 12/6/2016 10:44 AM, Jan Iversen wrote:

Well, Python/Java are ~7% of LOC in LibreOffice core repo, and less then 2%(?)
of the shipped core product.

But if I want to make an executable within the IDE,

No, that's not true. To make the executable within the IDE, the project file only needs to know the correct command to launch. That command is "make".

or debug e.g. some of the unit test I still need it.

Well, possibly *some* tests.

One of the hard points for new people is actually to be able to debug unit tests.

Currently, new people will be unable to debug a tiny amount of tests that really require Python/Java. Wast majority don't require that.

The simple use case, of being able to develop/build/debug within the
IDE....especially debugging is important. setting breakpoints on the lines
and viewing variables is what students learn todo.

Thats already possible with existing IDE integrations.
At least not in the Xcode integration.

for a couple of reasons (which might apply to windows as well, will test that later):
- the debugger cannot run, it has not main executable.
- make and Xcode puts objects in different places.
- Also it is important to see the relationship between modules (especially when searching for symbols).

Everything I write here is based on my own experience. I mainly develop under Windows, in VS 2013 IDE. And while specifically that integration cannot build within IDE, that's the smallest problem to launch the build from console.

Students want to do all development within the IDE, and I do not see why it should be impossible.

"All development within the IDE" (including breakpoints and debugging) is already
the status quo.

I might be doing something wrong, but I have until and including today, not being able to 1/ set a breakpoint 2/ press debug 3/ stop at the breakpoint, neither in windows nor in Xcode.

To debug, under Windows, you need to 'make CppunitTest_XXX CPPUNITTRACE=TRUE', which launches separate VS IDE that's ready to open source files, set breaks and press "Run". The instruction to do so is emitted when a unit test is failed.

So, IMO, there is simply small polishment required to fix some shortcomings of specific integrations, in your case, Xcode. Overall, the new gbuildtojson made things much better. I don't believe ve need some "IDE build systems".

--
Best regards,
Mike Kaganski

_______________________________________________
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: gbuildtojson

In reply to this post by jan iversen
Hi,

On Tue, Dec 06, 2016 at 08:44:04AM +0100, Jan Iversen wrote:
> I might be doing something wrong, but I have until and including today, not
> being able to 1/ set a breakpoint 2/ press debug 3/ stop at the breakpoint,
> neither in windows nor in Xcode.

This certainly is possible in Kdevelop: https://www.youtube.com/watch?v=-5hVXeHNt2M

It certainly was possible with VS: https://www.youtube.com/watch?v=Xn3CtIrMpIA

If it broke for VS, those on Windows devs need to take care of this regression.

Note Xcocde was started by Tor IIRC, and possibly never finished. Unless
someone takes clear ownership of that (and I assume Tor will not), consider it
nothing more than a starting point, not something to be intended for production
use as is.

> But you forget that we have many unit tests written in Java and python, which
> we ask new people to debug when they have problems.

I dont forget that. The pragmatic choice is to either have these tests fail in
such a clear way that you dont need a debugger to fix what was broken in C++ --
or, failing that, migrating them to C++. Note that the core implementation we
are testing is in C++ anyway, "people who can not read/write C++" is not
relevant. Only "people who are still new to C++, but want to learn are.

Having e.g. Python tests does not relieve possible contributors to learn C++
eventually. It only might make their migration to core code a bit easier.

The reason for having Python tests is not to conform possible contributors in
keeping away from C++. The reason for Python tests is that UNO test code is
quicker to write in Python (and Star Basic) than in C++ and since most test
code. Given that test code runs 99.99% of the time without failing and the need
for debugging that is a legitimate trade-off. For the 0.01% of cases were the
test fails, your test better makes clear what broke without needing to use a
debugger, or the test need to be migrated to C++ then.

> Simply put, to be able to debug in the IDE, make simple changes, run again
> and see the effect, which I still have not been able to do.

See above: Kdevelop always did that, VS demonstrated it at least at some point.
For other IDEs, I dont know if they ever promised that up to now, but given
Kdevelop/VS, it should be clear that they should be able to do that.

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: gbuildtojson

I never meant that the current work on gbuildtojson or x-ide-integration are bad or wrong….in my mind, it is very good, very needed work and especially the step away from interpreting the makefile output is very good, just a bit incomplete.

However I acknowledge the fact that I am quite alone with that opinion, which most likely means I am wrong in pursuing the goal I described.

Sorry for the noise on this list.
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: gbuildtojson

Hi,

On Tue, Dec 06, 2016 at 10:51:58AM +0100, Jan Iversen wrote:
> However I acknowledge the fact that I am quite alone with that opinion, which
> most likely means I am wrong in pursuing the goal I described.

Well, I still dont quite get what your goal is. If its to bring
xcode-ide-integration on par with kdevelop-ide-inegration and
vsXXXX-ide-integration -- thats of course nice.

Best,

Bjoern
_______________________________________________
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: gbuildtojson

Le 06/12/2016 à 11:49, Bjoern Michaelsen a écrit :

>
> Well, I still dont quite get what your goal is. If its to bring
> xcode-ide-integration on par with kdevelop-ide-inegration and
> vsXXXX-ide-integration -- thats of course nice.
>

Yes, it would be very nice ;-) In bringing into existence such a
capability, I might actually be able to contribute more usefully to
debugging, via my QA activities, particularly awkward bugs on OSX for
which no one has the time or inclination to look at.

Alex


_______________________________________________
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: gbuildtojson

Hi,

On Tue, Dec 06, 2016 at 01:41:33PM +0100, Alexander Thurgood wrote:
> Yes, it would be very nice ;-) In bringing into existence such a
> capability, I might actually be able to contribute more usefully to
> debugging, via my QA activities, particularly awkward bugs on OSX for
> which no one has the time or inclination to look at.

FWIW, for the time being Qt-Creator exists for OSX:

 http://doc.qt.io/qt-4.8/mac-support.html

and this commit:

 https://cgit.freedesktop.org/libreoffice/core/commit/?id=237a1b79a1d5af10434c2b93cfc83c1c8e55a9d5

says:

 "Developers can use use QtCreator to edit, compile and debug LibreOffice."

I dont know if it was ever tested on OSX, but it might be worth a try?

Best,

Bjoern

P.S.: If you get it working, please report back, because then we would have an
      IDE for all major plaforms: Kdevelop (Linux), Visual Studio (Windows),
      Qt-Creator (OSX). It would be valuable to keep these from regressing.
_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
Maxim Monastirsky Maxim Monastirsky
Reply | Threaded
Open this post in threaded view
|

Re: gbuildtojson

Hi Bjoern,

On Tue, 2016-12-06 at 15:22 +0100, Bjoern Michaelsen wrote:

> and this commit:
>
>  https://cgit.freedesktop.org/libreoffice/core/commit/?id=237a1b79a1d
> 5af10434c2b93cfc83c1c8e55a9d5
>
> says:
>
>  "Developers can use use QtCreator to edit, compile and debug
> LibreOffice."
>
> I dont know if it was ever tested on OSX, but it might be worth a
> try?

I don't know about OSX, but at least under Linux compile/run from
QtCreator doesn't work, and AFAIK never worked anywhere except for the
one who did that patch. The reason is that .pro.user files are _by
design_ installation-specific. They hardcode the "kit" identifier which
is unique for each installation. When you try to open this on a
different machine, the existing .pro.user files are simply ignored. So
unless we introduce some logic to detect the currently installed
QtCreator config folder, and get the kit identifier out of it, this is
not that useful for newcomers...

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

Re: gbuildtojson

CONTENTS DELETED
The author has deleted this message.
Maxim Monastirsky Maxim Monastirsky
Reply | Threaded
Open this post in threaded view
|

Re: gbuildtojson

Hi Khaled,

On Wed, 2016-12-07 at 00:46 +0200, Khaled Hosny wrote:
> I used it today to build and even run the binary, but I had to edit
> the
> project in QtCreator and remove the qmake build step (otherwise qmake
> will overwrite the Makefile and break the build).
>
> To run soffice I had also to manually add a run configuration that
> calls
> instdir/program/soffice.
Yes, that's exactly the problem I was talking about. We already
generate all those rules (take a look at .pro.user files right after
make qtcreator-ide-integration), but they are ignored by QtCreator
(which instead puts some default qmake stuff there). The current "fix"
is to open the .pro.user file in a text editor, and replace the id in:

<value type="QString"
key="ProjectExplorer.ProjectConfiguration.Id">{0701de51-c96e-4e4f-85c3-
e70b223c5076}</value>

with the one from ~/.config/QtProject/qtcreator/profiles.xml (the
PE.Profile.Id one).

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