Community
Participate
Working Groups
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.13) Gecko/2009082006 Iceweasel/3.0.12 (Debian-3.0.12-1) Build Identifier: 3.5 Currently the autotools plugin write a few times the current project name into .cproject. Examples: <configuration artifactExtension="" artifactName="myProject" ...> buildPath="${workspace_loc:/myProject/debug}" At least for references to directories it is probably not yet possible to avoid this as there exists no variable to access the absolute source directory. Stuff such as ${workspace_loc:/${ProjName}/debug}" is known to be fragile (found once a bug report for CDT?) and is parsed to "${ProjName}/debug}" IIRC. Nevertheless you probably agree that it is good idea to avoid using the project name in the file to simplify renaming. Reproducible: Always Autotools version: 0.3.0
(In reply to comment #0) > User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.13) > Gecko/2009082006 Iceweasel/3.0.12 (Debian-3.0.12-1) > Build Identifier: 3.5 > > Currently the autotools plugin write a few times the current project name into > .cproject. > > Examples: > <configuration artifactExtension="" artifactName="myProject" ...> > > buildPath="${workspace_loc:/myProject/debug}" > > At least for references to directories it is probably not yet possible to avoid > this as there exists no variable to access the absolute source directory. Stuff > such as ${workspace_loc:/${ProjName}/debug}" is known to be fragile (found once > a bug report for CDT?) and is parsed to "${ProjName}/debug}" IIRC. > > Nevertheless you probably agree that it is good idea to avoid using the > project name in the file to simplify renaming. > The build path specification in the .cproject file is done by the upstream CDT code and not part of the Autotools plugin. I am forwarding this on to the CDT folks. If you have a rename scenario that is failing, please add details here.
Correcting the CDT version number of the bug.
(In reply to comment #0) > <configuration artifactExtension="" artifactName="myProject" ...> bug 230165 was fixed - using ${ProjName} for artifact name now. > buildPath="${workspace_loc:/myProject/debug}" > At least for references to directories it is probably not yet possible to avoid > this as there exists no variable to access the absolute source directory. Stuff > such as ${workspace_loc:/${ProjName}/debug}" is known to be fragile (found once > a bug report for CDT?) and is parsed to "${ProjName}/debug}" IIRC. There was a bug 237448 which was fixed at least for include paths and it seems to be working for build directory too. Not sure about source folders though.
I renamed again a project using Eclipse but the buildLocation did not change properly: .project: <projectDescription> <buildSpec> <buildCommand> <name>org.eclipse.cdt.managedbuilder.core.genmakebuilder</name> <arguments> <dictionary> <key>org.eclipse.cdt.make.core.buildLocation</key> <value>${workspace_loc:/myProject}/debug</value> I expected to see myProjectNew instead of myProject. The problem with buildPath= in .cproject remains open as well. There is also the following entry in .cproject: <storageModule moduleId="cdtBuildSystem" version="4.0.0"> <project id="myProject.org.eclipse.linuxtools.cdt.autotools.core.projectType.1504544154" name="GNU Autotools" projectType="org.eclipse.linuxtools.cdt.autotools.core.projectType"/> </storageModule> Since I don't want to contain it the old name myProject I changed it. The corresponding file in my workspace (.metadata/.plugins/org.eclipse.core.runtime/.settings/org.eclipse.cdt.managedbuilder.core.prefs) seems not to contain important settings and I hope it will be filled with defaults for the new project name. I would much prefer having it in .settings/ as other stuff and assume it's just unimportant! CDT 3.6 M6 Autotools: daily snapshot
(In reply to comment #4) > I renamed again a project using Eclipse but the buildLocation did not change > properly: > > .project: > > <projectDescription> > <buildSpec> > <buildCommand> > <name>org.eclipse.cdt.managedbuilder.core.genmakebuilder</name> > <arguments> > <dictionary> > <key>org.eclipse.cdt.make.core.buildLocation</key> > <value>${workspace_loc:/myProject}/debug</value> > > I expected to see myProjectNew instead of myProject. > > The problem with buildPath= in .cproject remains open as well. > The previous two problems exist in the CDT. They occur for a regular ManagedMake project. I have opened an upstream bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=309225 > There is also the following entry in .cproject: > <storageModule moduleId="cdtBuildSystem" version="4.0.0"> > <project > id="myProject.org.eclipse.linuxtools.cdt.autotools.core.projectType.1504544154" > name="GNU Autotools" > projectType="org.eclipse.linuxtools.cdt.autotools.core.projectType"/> > </storageModule> > This data is also written by the CDT (not Autotools). We just happen to have a project type defined in the build definition. > Since I don't want to contain it the old name myProject I changed it. The > corresponding file in my workspace > (.metadata/.plugins/org.eclipse.core.runtime/.settings/org.eclipse.cdt.managedbuilder.core.prefs) > seems not to contain important settings and I hope it will be filled with > defaults for the new project name. I would much prefer having it in .settings/ > as other stuff and assume it's just unimportant! > > CDT 3.6 M6 > Autotools: daily snapshot
*** Bug 309225 has been marked as a duplicate of this bug. ***
I think that we should shoot for using ${ProjName} in those. Changing build directory to ${workspace_loc:/${ProjName}/Debug} when a project is created should be pretty straightforward (and I believe it works by now) if anybody wants to take a shot. Other places could be tricky.
*** Bug 461957 has been marked as a duplicate of this bug. ***
