973770 - Build backend that generates C/C++ Eclipse projects

Status: RESOLVED FIXED

(Firefox Build System :: General, defect)

Description

[Benoit Girard (:BenWa)]

+++ This bug was initially created as a clone of Bug #687388 +++

Similar to the Visual Studio generation we should generate an eclipse project. The eclipse cproject format is a bit more annoying to deal with then the MSBuild format but it's doable.

We have some documentation for the manual eclipse setup: https://developer.mozilla.org/en-US/docs/Eclipse_CDT

With moz.build we should be able to optimize this setup and ideally automate it.

Comment 1

[Benoit Girard (:BenWa)]

Attachment: Proof of concept (or throw away)

Here's a proof of concept. With this I can set defines per directory and build the project by invoke make binaries but it's still missing quite a bit to correctly index/auto-complete.

Comment 2

[Nick Alexander :nalexander [he/him]]

Comment on attachment 8377375 [details] [diff] [review]
Proof of concept (or throw away)

Review of attachment 8377375 [details] [diff] [review]:
-----------------------------------------------------------------

I'm thrilled to see some work building on the Android Eclipse backend so quickly!

::: python/mozbuild/mozbuild/backend/cpp_eclipse.py
@@ +78,5 @@
> +
> +        fh.write(CPROJECT_TEMPLATE_FOOTER)
> +
> +
> +PROJECT_TEMPLATE = """<?xml version="1.0" encoding="UTF-8"?>

Is there a strong reason to inline these rather than follow AndroidEclipse's suit and have directories and files in templates/?

@@ +119,5 @@
> +<?fileVersion 4.0.0?>
> +
> +<cproject storage_type_id="org.eclipse.cdt.core.XmlProjectDescriptionStorage">
> +        <storageModule moduleId="org.eclipse.cdt.core.settings">
> +                <cconfiguration id="0.1674256904">

I don't know much about Eclipse and CDT, but are these magic constants throughout random?

Comment 3

[Benoit Girard (:BenWa)]

(In reply to Nick Alexander :nalexander from comment #2)
> Comment on attachment 8377375 [details] [diff] [review]
> Proof of concept (or throw away)
> 
> Review of attachment 8377375 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> I'm thrilled to see some work building on the Android Eclipse backend so
> quickly!
> 
> ::: python/mozbuild/mozbuild/backend/cpp_eclipse.py
> @@ +78,5 @@
> > +
> > +        fh.write(CPROJECT_TEMPLATE_FOOTER)
> > +
> > +
> > +PROJECT_TEMPLATE = """<?xml version="1.0" encoding="UTF-8"?>
> 
> Is there a strong reason to inline these rather than follow AndroidEclipse's
> suit and have directories and files in templates/?

I felt like they were small enough to be inline and this was easier to prototype. We can consider splitting them out but I think it's fairly un-consequential.
> 
> @@ +119,5 @@
> > +<?fileVersion 4.0.0?>
> > +
> > +<cproject storage_type_id="org.eclipse.cdt.core.XmlProjectDescriptionStorage">
> > +        <storageModule moduleId="org.eclipse.cdt.core.settings">
> > +                <cconfiguration id="0.1674256904">
> 
> I don't know much about Eclipse and CDT, but are these magic constants
> throughout random?

Good question. It's this stuff that put me off from doing this sooner. The IDs just need to be unique from the looks of it. I'm not sure what eclipse uses to generate them. This ID comes from a test project where I copy pasted. You'll notice in elements that I repeat that we're generating an ID for it. I think leaving this id there is great but not ideal

We might be able to generate id like org.mozilla.cdt.<RANDOM>. We can try changing this at the end to see if it breaks.

Comment 4

[Benoit Girard (:BenWa)]

FWIW with the above project I set the std as c++11. Since with moz.build we should use the null build pass, as per mdn instructions, we need to find which options we need without having to use that script.

Comment 5

[Benoit Girard (:BenWa)]

Attachment: WIP

This now gets most of gecko indexed and auto-completing. Notably missing the ipdl header includes.

Comment 6

[Benoit Girard (:BenWa)]

Attachment: intellisense + mozilla style + run config + tabs_as_4space

The output generated projects work very well. It's only tested on Mac so perhaps a few tweaks will be needed for linux. Right now windows is a non goal.

Comment 7

[Gregory Szorc [:gps]]

Comment on attachment 8379511 [details] [diff] [review]
intellisense + mozilla style + run config + tabs_as_4space

Review of attachment 8379511 [details] [diff] [review]:
-----------------------------------------------------------------

Cool!

Parts of the generated Eclipse files assume ELF/non-Windows. Do you intend to support Eclipse on Windows? Should we enforce a !windows check in config_status.py?

I'm not super crazy about the large blocks of XML inline in the .py file. I think things might be a little cleaner if XML were loaded from external files and manipulations were performed via DOM. But, I'm willing to turn a blind eye until it becomes an issue.

I'll likely give this a quick r+ after it is rebased on top of central.

::: python/mozbuild/mozbuild/backend/cpp_eclipse.py
@@ +1,1 @@
> +import random

Need moar MPL.

@@ +49,5 @@
> +               self._macbundle = obj.defines['MOZ_MACBUNDLE_NAME']
> +           if 'MOZ_APP_NAME' in obj.defines and not obj.defines['MOZ_APP_NAME'][0] == '"':
> +               self._appname = obj.defines['MOZ_APP_NAME']
> +           if 'BIN_SUFFIX' in obj.defines:
> +               self._bin_suffix = obj.defines['BIN_SUFFIX']

You should be able to grab all these from self.environment.substs.

@@ +84,5 @@
> +        try:
> +            os.makedirs(workspace_language_dir)
> +        except OSError as e:
> +            if e.errno != errno.EEXIST:
> +                raise

That's a major DRY violation. Can we aggregate all the directories into a list or set and iterate over the try... os.makedirs bit?

@@ +137,5 @@
> +                exe_path = os.path.join(bin_dir, 'bin')
> +                
> +            exe_path = os.path.join(exe_path, self._appname + self._bin_suffix)
> +            launch = launch.replace('@LAUNCH_PROGRAM@', exe_path)
> +            launch = launch.replace('@LAUNCH_ARGS@', '-p DevProfile')

Hardcoding a profile seems less than ideal. Should we just launch with '-no-remote -ProfileManager'

@@ +164,5 @@
> +            folderinfo = folderinfo.replace('@FOLDER_ID@', str(random.randint(1000000, 99999999999)))
> +            folderinfo = folderinfo.replace('@FOLDER_NAME@', 'tree/' + path)
> +            fh.write(folderinfo)
> +            for k, v in defines.items():
> +                fh.write(CPROJECT_TEMPLATE_FOLDER_INFO_DEFINE.replace('@FOLDER_DEFINE@', str(k) + "=" + self._define_escape(str(v))))

Manual XML encoding makes me sad. Can you not perform the text substitution inside a DOM node and let the XML library handle the escaping?

::: python/mozbuild/mozbuild/config_status.py
@@ +16,5 @@
>  
>  from mach.logging import LoggingManager
>  from mozbuild.backend.configenvironment import ConfigEnvironment
>  from mozbuild.backend.android_eclipse import AndroidEclipseBackend
> +from mozbuild.backend.cpp_eclipse import CppEclipseBackend

This should be lazy imported only if the backend is active.

Also, this file needs rebased on top of m-c.

Comment 8

[Benoit Girard (:BenWa)]

(In reply to Gregory Szorc [:gps] from comment #7)
> Comment on attachment 8379511 [details] [diff] [review]
> intellisense + mozilla style + run config + tabs_as_4space
> 
> Review of attachment 8379511 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> Cool!
> 
> Parts of the generated Eclipse files assume ELF/non-Windows. Do you intend
> to support Eclipse on Windows? Should we enforce a !windows check in
> config_status.py?

Yes, for now let's focus on !windows and later we can certify it for windows if people want to use eclipse over Visual Studio which initially we should recommend against.

> 
> I'm not super crazy about the large blocks of XML inline in the .py file. I
> think things might be a little cleaner if XML were loaded from external
> files and manipulations were performed via DOM. But, I'm willing to turn a
> blind eye until it becomes an issue.

Here's my arguments that we should leave the files in:
* The XML logically belongs to the file so it make sense to keep the groupping
* It's easy to forgot the files in the tree when we remove the *.py
* The XML aren't shared by anything else
* Needless files makes HG use the filesystem more.

> 
> I'll likely give this a quick r+ after it is rebased on top of central.
> 
> ::: python/mozbuild/mozbuild/backend/cpp_eclipse.py
> @@ +1,1 @@
> > +import random
> 
> Need moar MPL.
> 
> @@ +49,5 @@
> > +               self._macbundle = obj.defines['MOZ_MACBUNDLE_NAME']
> > +           if 'MOZ_APP_NAME' in obj.defines and not obj.defines['MOZ_APP_NAME'][0] == '"':
> > +               self._appname = obj.defines['MOZ_APP_NAME']
> > +           if 'BIN_SUFFIX' in obj.defines:
> > +               self._bin_suffix = obj.defines['BIN_SUFFIX']
> 
> You should be able to grab all these from self.environment.substs.
> 

Thanks, was hoping you knew a better way.

> 
> Hardcoding a profile seems less than ideal. Should we just launch with
> '-no-remote -ProfileManager'

The profile manager causes the process the relaunch which gdb doesn't handle. Not sure if eclipse does. It also needless clicking. Ideally we need a better solution.

> 
> @@ +164,5 @@
> > +            folderinfo = folderinfo.replace('@FOLDER_ID@', str(random.randint(1000000, 99999999999)))
> > +            folderinfo = folderinfo.replace('@FOLDER_NAME@', 'tree/' + path)
> > +            fh.write(folderinfo)
> > +            for k, v in defines.items():
> > +                fh.write(CPROJECT_TEMPLATE_FOLDER_INFO_DEFINE.replace('@FOLDER_DEFINE@', str(k) + "=" + self._define_escape(str(v))))
> 
> Manual XML encoding makes me sad. Can you not perform the text substitution
> inside a DOM node and let the XML library handle the escaping?

I'm not using an XML library. What do you suggest I use?

Comment 9

[Nick Alexander :nalexander [he/him]]

> Here's my arguments that we should leave the files in:
> * The XML logically belongs to the file so it make sense to keep the
> groupping

I specifically anticipated folks doing this type of preprocessing during project building, and added backend/templates for it.  Why not use it?  We could even share helper code for the iteration and installation!

> * It's easy to forgot the files in the tree when we remove the *.py

Point.

> * The XML aren't shared by anything else

Sure is hard to understand when it's mixed into sourcecode.

> * Needless files makes HG use the filesystem more.

This is bullshit.
 
> > Manual XML encoding makes me sad. Can you not perform the text substitution
> > inside a DOM node and let the XML library handle the escaping?
> 
> I'm not using an XML library. What do you suggest I use?

Python ships with XML support; see ElementTree and minidom.

Comment 10

[Benoit Girard (:BenWa)]

(In reply to Nick Alexander :nalexander from comment #9)
> > * Needless files makes HG use the filesystem more.
> 
> This is bullshit.
>  

This is not acceptable. If you wish to rebut my argument do so with technical arguments.

Comment 11

[Nick Alexander :nalexander [he/him]]

(In reply to Benoit Girard (:BenWa) from comment #10)
> (In reply to Nick Alexander :nalexander from comment #9)
> > > * Needless files makes HG use the filesystem more.
> > 
> > This is bullshit.
> >  
> 
> This is not acceptable. If you wish to rebut my argument do so with
> technical arguments.

Yeah, sorry, clicked save and regretted it.  Arguing that separating code from data is a bad idea because the VCS will incur overhead is itself a weak technical argument.  There are many places in the tree where we could save many files, but we don't, because separating concerns is valuable.

Comment 12

[Gregory Szorc [:gps]]

See python/mozbuild/mozbuild/backend/visualstudio.py for examples of how to do XML manipulation in Python. ElementTree is easy. But you might as well use DOM because it's, well, DOM, and you won't paint yourself in a corner if you need to do something ElementTree won't let you.

We have 90800+ files in a mozilla-central checkout. Adding a few files is not going to make hg or git much slower and should not be used as a reason to not split out the XML.

Comment 13

[Mike Hommey [:glandium]]

I'll add that generating XML by string concatenation or formatting is the best way to create invalid XML.

Comment 14

[Benoit Girard (:BenWa)]

Attachment: intellisense + mozilla style + run config + tabs_as_4space. v2

I converted the XML escaping to use ElementTree since it did exactly what I need. If we converted all the project generation to be done manually in python then we should use DOM. I don't think doing that now is a good use of time and is likely very error prone without a current need.

I left the XML data at the bottom of the file. I could be convinced to move them into files.

Comment 15

[Botond Ballo [:botond]]

Attachment: Backport to b2g 1.3

I backported the patch to the b2g 1.3 branch and I'm posting it now so people who would like to test it out there can do so.

Comment 16

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Comment on attachment 8381874 [details] [diff] [review]
intellisense + mozilla style + run config + tabs_as_4space. v2

Review of attachment 8381874 [details] [diff] [review]:
-----------------------------------------------------------------

::: python/mozbuild/mozbuild/backend/cpp_eclipse.py
@@ +86,5 @@
> +            fh.write(WORKSPACE_LANGUAGE_SETTINGS_TEMPLATE)
> +
> +        self._write_launch_files(launch_dir)
> +
> +        # This will show up as an 'unmanged' formater. This can be named by generating

"formatter" (same typo repeated in several places)

@@ +116,5 @@
> +            if self._macbundle:
> +                exe_path = os.path.join(bin_dir, self._macbundle, 'Contents/MacOS')
> +            else:
> +                exe_path = os.path.join(bin_dir, 'bin')
> +                

trailing whitespace

@@ +287,5 @@
> +                                                        <flag value="LOCAL"/>
> +                                                </entry>
> +                                                <entry kind="includeFile" name="@PREINCLUDE_FILE_PATH@">
> +                                                        <flag value="LOCAL"/>
> +                                                </entry>

In my projects I add mozilla-config.h as an always-included file so that the indexer knows every translation unit has it. I don't think this patch does that yet?

Comment 17

[Benoit Girard (:BenWa)]

> @@ +287,5 @@
> > +                                                        <flag value="LOCAL"/>
> > +                                                </entry>
> > +                                                <entry kind="includeFile" name="@PREINCLUDE_FILE_PATH@">
> > +                                                        <flag value="LOCAL"/>
> > +                                                </entry>
> 
> In my projects I add mozilla-config.h as an always-included file so that the
> indexer knows every translation unit has it. I don't think this patch does
> that yet?

This will be project wide. Unless there's a bug I'm missing.

Comment 18

[Gregory Szorc [:gps]]

mozilla-config.h is added by everything that compiles through config.mk, which is everything except the external projects.

Unless these Eclipse projects are capturing external projects (external to the build system like ICU), you should force include mozilla-config.h.

Comment 19

[Benoit Girard (:BenWa)]

Comment on attachment 8381874 [details] [diff] [review]
intellisense + mozilla style + run config + tabs_as_4space. v2

Review of attachment 8381874 [details] [diff] [review]:
-----------------------------------------------------------------

::: python/mozbuild/mozbuild/backend/cpp_eclipse.py
@@ +101,5 @@
> +        settings = LANGUAGE_SETTINGS_TEMPLATE
> +
> +        settings = settings.replace('@GLOBAL_INCLUDE_PATH@', os.path.join(self.environment.topobjdir, 'dist/include'))
> +        settings = settings.replace('@IPDL_INCLUDE_PATH@', os.path.join(self.environment.topobjdir, 'ipc/ipdl/_ipdlheaders'))
> +        settings = settings.replace('@PREINCLUDE_FILE_PATH@', os.path.join(self.environment.topobjdir, 'dist/include/mozilla-config.h'))

This is already done here:
mozilla-config, dist/include, ipdlheaders are manually added to the whole project.

Because of the limitations in the indexer where it sometimes fails to reindex files if the preprocessor context differs my solution only supports the XUL project.

Comment 20

[Benoit Girard (:BenWa)]

Eclipse 8.3 is being released soon-ish. Well need to check if they added some feature that can help us tweak the index header behaviors that are hurting us. All in a follow up of course. This for now will work best with Eclipse CDT 8.2.

Comment 21

[Gregory Szorc [:gps]]

Expect a full review shortly. In the mean time, here's what my Python lint Mercurial hook said:

My Python lint Mercurial hook says:

python/mozbuild/mozbuild/backend/cpp_eclipse.py:12:1: F401 'LibraryDefinition' imported but unused
python/mozbuild/mozbuild/backend/cpp_eclipse.py:12:1: F401 'LocalInclude' imported but unused
python/mozbuild/mozbuild/backend/cpp_eclipse.py:12:1: F401 'Program' imported but unused
python/mozbuild/mozbuild/backend/cpp_eclipse.py:12:1: F401 'VariablePassthru' imported but unused
python/mozbuild/mozbuild/backend/cpp_eclipse.py:120:1: W293 blank line contains whitespace
python/mozbuild/mozbuild/backend/cpp_eclipse.py:212:1: W191 indentation contains tabs
python/mozbuild/mozbuild/backend/cpp_eclipse.py:217:1: W191 indentation contains tabs
python/mozbuild/mozbuild/backend/cpp_eclipse.py:218:1: W191 indentation contains tabs
python/mozbuild/mozbuild/backend/cpp_eclipse.py:219:1: W191 indentation contains tabs
python/mozbuild/mozbuild/backend/cpp_eclipse.py:220:1: W191 indentation contains tabs
python/mozbuild/mozbuild/backend/cpp_eclipse.py:221:1: W191 indentation contains tabs
python/mozbuild/mozbuild/backend/cpp_eclipse.py:224:1: W191 indentation contains tabs
python/mozbuild/mozbuild/backend/cpp_eclipse.py:227:1: W191 indentation contains tabs
python/mozbuild/mozbuild/backend/cpp_eclipse.py:228:1: W191 indentation contains tabs
python/mozbuild/mozbuild/backend/cpp_eclipse.py:229:1: W191 indentation contains tabs
python/mozbuild/mozbuild/backend/cpp_eclipse.py:230:1: W191 indentation contains tabs
python/mozbuild/mozbuild/backend/cpp_eclipse.py:231:1: W191 indentation contains tabs
python/mozbuild/mozbuild/backend/cpp_eclipse.py:295:129: W291 trailing whitespace

Comment 22

[Benoit Girard (:BenWa)]

Review ping.

This patch is really trivial, small and provides a large productivity win for developers. There's no security risk and barely any maintenance concerns as it keeps all changes practically isolated to its own file. All I'm looking for here is a rubber stamp to move on and continue improving this. Slow review times and excessive nitpicking is very frustrating when that time could be spent improving this in non trivial ways.

Comment 23

[Gregory Szorc [:gps]]

Sorry. I've been giving post-surgery care to a loved one this week and my review queue has suffered. I'll try to look at this shortly.

Comment 24

[Gregory Szorc [:gps]]

Comment on attachment 8381874 [details] [diff] [review]
intellisense + mozilla style + run config + tabs_as_4space. v2

Review of attachment 8381874 [details] [diff] [review]:
-----------------------------------------------------------------

While I would like to see some basic smoke tests, I think this is good enough to land. We can always add robustness later.

::: python/mozbuild/mozbuild/backend/cpp_eclipse.py
@@ +53,5 @@
> +
> +        reldir = getattr(obj, 'relativedir', None)
> +
> +        if isinstance(obj, Defines):
> +            self._paths_to_defines.setdefault(reldir, {}).update(obj.defines)

The Visual Studio projects record include paths. I'm kind of impressed Eclipse doesn't need this!

@@ +115,5 @@
> +            # TODO Improve binary detection
> +            if self._macbundle:
> +                exe_path = os.path.join(bin_dir, self._macbundle, 'Contents/MacOS')
> +            else:
> +                exe_path = os.path.join(bin_dir, 'bin')

We have an API for this in MozbuildObject, but it's not easy to get at from this context. Meh.

::: python/mozbuild/mozbuild/config_status.py
@@ +122,5 @@
> +    elif options.backend == 'CppEclipse':
> +        from mozbuild.backend.cpp_eclipse import CppEclipseBackend
> +        backend_cls = CppEclipseBackend
> +        if os.name == 'nt':
> +          raise Exception('Eclipse is not supported on Windows. Consider using Visual Studio instead.')

Do you want to throw a "yet" in here?

Comment 25

[Benoit Girard (:BenWa)]

(In reply to Gregory Szorc [:gps] from comment #24)
> Comment on attachment 8381874 [details] [diff] [review]
> intellisense + mozilla style + run config + tabs_as_4space. v2
> 
> Review of attachment 8381874 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> While I would like to see some basic smoke tests, I think this is good
> enough to land. We can always add robustness later.
> 
> ::: python/mozbuild/mozbuild/backend/cpp_eclipse.py
> @@ +53,5 @@
> > +
> > +        reldir = getattr(obj, 'relativedir', None)
> > +
> > +        if isinstance(obj, Defines):
> > +            self._paths_to_defines.setdefault(reldir, {}).update(obj.defines)
> 
> The Visual Studio projects record include paths. I'm kind of impressed
> Eclipse doesn't need this!

I'll put a comment in the code since it's a bit odd. It's sort of a side benefit of eclipse 'crappy' indexer that doesn't truely use the build flags and just crawls headers.

> 
> @@ +115,5 @@
> > +            # TODO Improve binary detection
> > +            if self._macbundle:
> > +                exe_path = os.path.join(bin_dir, self._macbundle, 'Contents/MacOS')
> > +            else:
> > +                exe_path = os.path.join(bin_dir, 'bin')
> 
> We have an API for this in MozbuildObject, but it's not easy to get at from
> this context. Meh.

Yea, I was looking for it. This is a bit sucky. This code will get worse as we add support for mobile which I want to do as a follow up. *sigh*

> 
> ::: python/mozbuild/mozbuild/config_status.py
> @@ +122,5 @@
> > +    elif options.backend == 'CppEclipse':
> > +        from mozbuild.backend.cpp_eclipse import CppEclipseBackend
> > +        backend_cls = CppEclipseBackend
> > +        if os.name == 'nt':
> > +          raise Exception('Eclipse is not supported on Windows. Consider using Visual Studio instead.')
> 
> Do you want to throw a "yet" in here?

No. I'm not signing up for this work unless there's strong demand. I'd rather push visual studio on windows personally. I could see people preferring eclipse on windows for consistency so I want to wait for feedback.

Anyone want to convince me that they really prefer Eclipse on windows above Visual Studio?

As a side note the JetBrains C++ IDE is something worth watching as another potential target/replacement for this.

Comment 26

[Gregory Szorc [:gps]]

You may also want to throw some docs into build/docs. As long as |mach build-docs| works, you don't need review for adding this and can checkin docs-only changes with NPOTB.

Comment 27

[Benoit Girard (:BenWa)]

(In reply to Gregory Szorc [:gps] from comment #21)
> python/mozbuild/mozbuild/backend/cpp_eclipse.py:120:1: W293 blank line
> contains whitespace
> python/mozbuild/mozbuild/backend/cpp_eclipse.py:212:1: W191 indentation
> contains tabs
> python/mozbuild/mozbuild/backend/cpp_eclipse.py:217:1: W191 indentation
> contains tabs
> python/mozbuild/mozbuild/backend/cpp_eclipse.py:218:1: W191 indentation
> contains tabs
> python/mozbuild/mozbuild/backend/cpp_eclipse.py:219:1: W191 indentation
> contains tabs
> python/mozbuild/mozbuild/backend/cpp_eclipse.py:220:1: W191 indentation
> contains tabs
> python/mozbuild/mozbuild/backend/cpp_eclipse.py:221:1: W191 indentation
> contains tabs
> python/mozbuild/mozbuild/backend/cpp_eclipse.py:224:1: W191 indentation
> contains tabs
> python/mozbuild/mozbuild/backend/cpp_eclipse.py:227:1: W191 indentation
> contains tabs
> python/mozbuild/mozbuild/backend/cpp_eclipse.py:228:1: W191 indentation
> contains tabs
> python/mozbuild/mozbuild/backend/cpp_eclipse.py:229:1: W191 indentation
> contains tabs
> python/mozbuild/mozbuild/backend/cpp_eclipse.py:230:1: W191 indentation
> contains tabs
> python/mozbuild/mozbuild/backend/cpp_eclipse.py:231:1: W191 indentation
> contains tabs
> python/mozbuild/mozbuild/backend/cpp_eclipse.py:295:129: W291 trailing
> whitespace

These are in the trippled quoted string. These are intentional for the XML to come out as human readable when generated which is handy for debugging & extending. This shouldn't warn for strings.

Comment 28

[Benoit Girard (:BenWa)]

(In reply to Gregory Szorc [:gps] from comment #26)
> You may also want to throw some docs into build/docs. As long as |mach
> build-docs| works, you don't need review for adding this and can checkin
> docs-only changes with NPOTB.

I included these part of my patch. They are fairly copy and pasted from AndroidEclipse (I filed a bug to unify Cpp/Android Eclipse). I also split off a section for IDE in the build docs.

Comment 29

[Benoit Girard (:BenWa)]

Attachment: patch v3 r=gps

Alright so I just tried this with Eclipse CDT 8.3 and the indexer can't parse things properly.

I think I'm going to land this and file a follow up to deal with the remaining issues. Until then we wont advertise this yet.

Comment 30

[Benoit Girard (:BenWa)]

http://hg.mozilla.org/integration/mozilla-inbound/rev/3069330887e4

Follow up bug 980183 to support 8.3.

Comment 31

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/3069330887e4

Comment 32

[Benoit Girard (:BenWa)]

Comment on attachment 8386558 [details] [diff] [review]
patch v3 r=gps

Asking for botond to take a look at the eclipse bits of the patch more in depth.

Comment 33

[Benoit Girard (:BenWa)]

Attachment: Launch typo fix

Comment 34

[Benoit Girard (:BenWa)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/c8b8c88384a4

Comment 35

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/c8b8c88384a4

Comment 36

[:garvan]

I am getting tons of errors after importing the project:
https://www.dropbox.com/s/rzw0ku1ynm7ll6f/Screenshot%202015-01-13%2015.55.48.png

What I see is that build/rebuild through Eclipse runs (no errors reported in the Problems tab). However, every file I open, problems are then found and reported.

Here is the Console tab output showing no errors after build:
https://pastebin.mozilla.org/8202272

I have only basic Eclipse knowledge, so a setup error is a possibility in my case.

Comment 37

[Benoit Girard (:BenWa)]

The full codebase isn't fully understood by eclipse. This is expected sadly.

Comment 38

[Daosheng Mu[:daoshengmu]]

Hi Benoit,
I am using your backend to generate the eclipse project for Gecko on Mac and Ubuntu. Eclipse can make us feel comfortable to view code due to the C++ Index. But it is a little bit weird on debugging. I can place breakpoints and debug on the functions of nsBrowserApp.cpp, but at other files, it will not work. The gdb process will not enter the breakpoints.

Comment 39

[:garvan]

I don't think this project uses the unified sources, rather it compiles cpps directly. I had a similar problem in xcode proj generation (bug 1063329) which was solved by using the unified sources as compilation units (members of a compilation target) and their included cpps added to the project but not part of any build target.

Comment 40

[Benoit Girard (:BenWa)]

Debugging is not supported by the project generation. Someone would have to figure how to get eclipse to understand it.

Comment 41

[Botond Ballo [:botond]]

Comment on attachment 8386558 [details] [diff] [review]
patch v3 r=gps

I think it's fair to say I'm not going to get around to taking that more detailed look at this patch that I had been meaning to. Eclipse's XML project format is an aging, arcane, and unmaintained thing and there's little justification for me to delve into it.

In any case, the Eclipse project generator has served us well enough over the past few years and is continuing to do so thanks to jwatt's efforts. Thank you BenWa for writing it in the first place.