Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] Question about .cproject files.

Thanks for your prompt reply.  It was indeed using CDT 8.1.1.  Updating fixed my problem, and I'm off to the races.  I'll be very happy to be able to use the Eclipse CDT, and ditch Emacs and Gnu Global.

It seems as if generating a uniquely generated string works.  I've tried it with another formulation of this generation script, and it seems to be working pretty well.  I'll ask if I can post the script.  I think it might be of general interest, and not really very proprietary.  But since I did it on the company dime I ought to get their permission to post it.

Good luck.

On Fri, Feb 22, 2013 at 3:35 PM, Oberhuber, Martin <Martin.Oberhuber@xxxxxxxxxxxxx> wrote:

Hi Bill,


What version of CDT are you using ?


8.1.1 had a defect which disabled the Language Settings Providers:


Your other issue of not picking up the includes seems to be a refresh problem of some sort after you enable the LSP’s.

Personally, I’d recommend you pick up the CDT 8.1.2 candidate, which is build #408 from Hudson:


Or, you don’t use the Language Settings Providers but the older PathEntry mechanism.


Coincidentally, your question about whether it’s valid to just generate some fake ID’s applies to myself as well right now ; I’m also generating projects from templates and I’m wondering whether the ID’s just need to be unique in project scope or whether they need to be unique in workspace scope. I think that being able to generate projects is important, so I’d love to see CDT either doing away with these ID’s or explaining clearly their semantics.





Martin Oberhuber, SMTS / Product Architect – Development Tools, Wind River

direct +43.662.457915.85  fax +43.662.457915.6


From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Bill White
Sent: Friday, February 22, 2013 7:40 PM
To: CDT General developers list.
Subject: [cdt-dev] Question about .cproject files.


Hi.  I apologize if this is the wrong list, but I'm not sure what the right one is.


I'm trying to figure out how to create eclipse CDT projects from scratch, not using eclipse.  


The problem is that I have many modules, about 1000, each of which is logically an eclipse project.  For each module I have a lot of configuration data, such as the module dependences, include paths and -D defines.  These are used to generate Microsoft Visual C++ projects and XCode projects.  It seemed to me that I could generate a CDT project with this data, if I understood the .cproject and .project format.  There seems to be some independent interest in doing this, as there are several questions about it on StackExchange and in the CDT forums.


So, I created a project which was configured as I expected it to be, but with the include files and defines set to a dummy value.  In particular, I enabled the language settings.  (This was the default, I think, so I just left it enabled.)  I then looked at the resulting .cproject file, and noticed that it had a lot of elements with "id" attribute equal to "a.b.c.N", where "a.b.c" looks like a java package name, and N is a big number.  I guessed that N is a hash value with serves to make things unique in a workspace, but that its numeric value is not important.  This is just a guess.  I wrote a python program to replace these names with XSLT style variables, and thereby extract an XSLT template from the pattern .cproject file.  I did the same with a .project file.  Then, combining the XSLT template with the XML file describing the project (and some small amount of glue) I can produce a .project and .cproject file.


My problem is that I can't seem to figure out how to make eclipse take into account the built-in gcc include path in the generated .cproject file.  When I import the generated file, the setting "C++ General > Preprocessor Includes, Macros etc. > Enable Language Settings for this Project" has been changed from enabled, as it was in my original pattern, to disabled.  When I enable it, the built-in includes show up in the include list in the Project Explorer list.  But in my source code an include line like:

  #include <sstream>

is not resolvable by the CDT.  The include list has "/usr/include/c++/4.4" and inside this folder is a file called "sstream", and I can open it.  However, the CDT doesn't seem to see it.


Is there something I should do to force language settings to be enabled in my generated project?  Is there some other setting I'm not understanding to include the built-in include paths?  Is this whole endeavor doomed to failure?  (I think the answer to the last question is false, since CMake can make an Eclipse C++ project.  I can't really use CMake, because I'm not in control of the build process.)




cdt-dev mailing list

Back to the top