make gbuildtojson

classic Classic list List threaded Threaded
4 messages Options
jan iversen jan iversen
Reply | Threaded
Open this post in threaded view
|

make gbuildtojson

Hi

2 questions about gbuildtojson.

Currently the filenames are stripped for their type in the json file. <Foo>-ide-integration, need the filetype for each file. Can I please have a hint in which gb_ function the stripping happens?

Considering that gbuild-to-ide.py should not be converted to C++, would it not be better to convert gbuildtojson.cxx to python. That way we use the same language for the 2 parts, and in python we can easier make the json object more splitted ready to use for the ide generators ?

I will do the changes.

As a sidenote, xcodeproj files now loads correctly, with the exception of json with multiple targets. My intention is keep vs2013 in parallel.

My timeline is to have a working solution (not complete) at the hackfest after FOSDEM, giving us a chance to set the final goals.

rgds
han 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

Hey Jan,

On Mon, Dec 26, 2016 at 12:02 PM, jan iversen <[hidden email]> wrote:
Hi

2 questions about gbuildtojson.

Currently the filenames are stripped for their type in the json file. <Foo>-ide-integration, need the filetype for each file. Can I please have a hint in which gb_ function the stripping happens?


So I think that it is not really stripped at all. In contrast we leave the file extension from the name in the makefile and handle it by using the same extension for all files of the same type. In the case that the suffix does not match the type that we specify, e.g. external libraries with cpp files and our own makefiles we set the suffix explicitly.

As an example any object mentioned with add_exception_objects is a c++ file with the cxx file extension and exceptions being enabled. In contrast add_cobjects is e.g. a c file with a .c extension and add_objcxxobjects is a objective-c file with a .mm file extension.

Considering that gbuild-to-ide.py should not be converted to C++, would it not be better to convert gbuildtojson.cxx to python. That way we use the same language for the 2 parts, and in python we can easier make the json object more splitted ready to use for the ide generators ?


So I'm not sure if that is worth it but would not object the change. At least for me the gbuildtojson script should be stable and low maintenance. We will never be able to keep all IDE generators up to date so changes to the gbuildtojson output should be considered as something that should be mostly done in a backward compatible way. Obviously if there are good arguments for having it in python we should rewrite it in python, just the fact that another script in the gbuild-to-ide pipeline is a python script is maybe not enough.
 

I will do the changes.

As a sidenote, xcodeproj files now loads correctly, with the exception of json with multiple targets. My intention is keep vs2013 in parallel.

My timeline is to have a working solution (not complete) at the hackfest after FOSDEM, giving us a chance to set the final goals.

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

Regards,
Markus


_______________________________________________
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


As an example any object mentioned with add_exception_objects is a c++ file with the cxx file extension and exceptions being enabled. In contrast add_cobjects is e.g. a c file with a .c extension and add_objcxxobjects is a objective-c file with a .mm file extension. 

I see that, but I am confused, e.g. in Library_AppleRemote.mk contains:
$(eval $(call gb_Library_add_objcobjects,AppleRemote,\
which is a .mm file

I will go through the *.mk and find all the non C++ files, and see if gbuildtojson builds correct json objects.

But at least now I know why the genlang json has wrong information, there we use .l (flex) files.


So I'm not sure if that is worth it but would not object the change. At least for me the gbuildtojson script should be stable and low maintenance. We will never be able to keep all IDE generators up to date so changes to the gbuildtojson output should be considered as something that should be mostly done in a backward compatible way. Obviously if there are good arguments for having it in python we should rewrite it in python, just the fact that another script in the gbuild-to-ide pipeline is a python script is maybe not enough.

Good point, I will leave it as it is.

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

Hi,

On Wed, Dec 28, 2016 at 09:25:48AM +0100, Jan Iversen wrote:
> I see that, but I am confused, e.g. in Library_AppleRemote.mk contains:
> $(eval $(call gb_Library_add_objcobjects,AppleRemote,\
> which is a .mm file

Eh? There is C and C++. And there is objective C and C++. All those _four_
cases are slightly different.

Best,

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