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.

The .xsl files could be generated by hand, but (1) I didn't know exactly what they were supposed to look like, and (2) I thought it would be easier to use Eclipse to make an example project, convert the example project metadata files to template metadata files and then tune them for each of the real modules.  Turning the example metadata to the XSL Template metadata is what the python script does.  Opinions may vary, and either make sense.


On Sun, Feb 24, 2013 at 3:39 PM, Oberhuber, Martin <Martin.Oberhuber@xxxxxxxxxxxxx> wrote:

Thanks Bill.

 

Sounds like the “project.xsl” and “cproject.xsl” could also be hand-written without Python since they are static, right ?

 

Just note that when you’re using the new LanguageSettingsProviders, you may also have to generate some Java Properties files in the .settings folder to make your project complete; and if you want your generated projects to also support additional add-on natures (like findbugs, doxygen, …) you might have to copy/generate even more files from your template.

 

In my case, I’m just copying template projects into the workspace and I’m living with multiple projects having identical ID’s … so far, it looks like it works OK with the ID’s being unique only on project scope but we haven’t tested a lot yet.

 

Thanks,

Martin

--

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: Saturday, February 23, 2013 6:14 PM
To: CDT General developers list.
Subject: Re: [cdt-dev] Question about .cproject files.

 

It's not all that impressive or, really, very efficient.

·         I get an xml file from our build system which contains the -I's and -D's.  It has some other stuff, like module names and relative paths to modules, but these are all specific to us.

·         I have a python script which reads a .project and a .cproject file using python's XML parsing module.  It looks for attributes named "id" whose values match a given regular _expression_, and replaces the value with an xlst variable.  The then looks for option elements whose valueType(?) attribute is "includePath", and replaces them with an <xsl:foreach> element.  Finally, it wraps the whole thing in an <xsl:transform> node and dumps to files cproject.xsl and project.xsl.  These are xslt transform programs.

·         I have a shell script with futzes around with envariables to figure out where the xslt files are, where the sources are and where the workspace is, and then calls the unix program xsltproc to transform the file in bullet (1) to .cproject and .project files.

The whole think took me about two days.  It would have taken less, but I didn't know anything about python's XML module or xslt.  I had to read up on just enough of them to get what I needed.  Someone competent could probably do the job in a few hours.

I'll see what I can do.

 

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

Seeing that script would indeed be interesting.

 

Thanks,

Martin

--

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 10:11 PM


To: CDT General developers list.

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

https://bugs.eclipse.org/bugs/show_bug.cgi?id=393641

 

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:

https://hudson.eclipse.org/hudson/job/cdt-maint/408/

 

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.

 

Thanks,

Martin

--

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

 

Thanks.

 


_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev

 


_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev

 


_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev



Back to the top