Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Language IDEs » C / C++ IDE (CDT) » [SOLVED] Out-of-source auto-tools build(Separate build configurations in different folders)
icon9.gif  [SOLVED] Out-of-source auto-tools build [message #1422352] Fri, 12 September 2014 18:33 Go to next message
Alex Mising name is currently offline Alex Mising nameFriend
Messages: 149
Registered: March 2010
Senior Member
Hello,

I am a new user of CDT. I want to work on an auto-tools project using GNU gcc. Details on my environment are at the end of this post. My problem is that I can only get CDT builds to work when building alongside the source directory. I would create "debug" and "release" sub-folders and run configure within those folders. I mean the usual approach of things like:

mkdir debug ; cd debug
CFLAGS="-g3 -O0" ../configure

Although my goal is to work on an existing project, I tried creating one from scratch, to see if this can be done. So I invoked the new project wizard:

New -> Project... ->  C/C++ -> C++ Project
Name: testauto
Project type: GNU Autotools -> Autotools Shared Library Project


I was then prompted for Build configurations. I think this is where I am supposed to configure what I want (separate folder, different CFLAGS). In any case, I accepted the default "Build (GNU)" that was already present and pressed "Finish". At this point I can build and run the project just fine:

Right-click on project -> Reconfigure (this ran "autoreconf -i" successfully)
Right-click on project -> Build Project (this ran "make all" successfully)


I could see Binaries and Archives with both the shared library and exampleProgram, created a launch configuration, ran it, everything was perfect. BUT it was compiling alongside the sources. I want to set custom CFLAGS and build in a separate directory. So I tried this:

Right-click on project -> Build Configurations -> Manage
New... (note that I could see the default "Build (GNU)" which was checked here)


Now in this dialog there was a message at the top which read:

Quote:
Note: The configuration name will be used as a directory name in the file system. Please ensure that it is valid for your platform.


Splendid, exactly what I want! I typed the name "Debug" and description "No optimizations and full symbols" and found the promising "Shared Library -> MacOSX GCC -> Debug" in the drop-down next to "Import predefined". True to its promise, CDT created a "Debug" folder and ran "make distclean" at the top-level folder to tidy up, followed by a switch to the new "Debug" sub-folder in which it ran configure. In the console log I see that this completed successfully. In fact it was followed by a "make clean" was also successful, but then I got a modal error dialog with:

Errors occurred during the build.
Errors running builder 'CDT Builder' on project 'test'.
A resource exists with a different case: '/test/Debug/Makefile'.
A resource exists with a different case: '/test/Debug/Makefile'.


No output was produced, but there was nothing in the console log output to indicate an error.

Now, I don't what it THINKS is wrong there, but the fact is that everything is ok. If I open up a terminal and go to <workspace>/test/Debug, then running "make" works fine. (To be perfectly honest, it fails when linking because the new project wizard generates a Makefile.am with "exampleProgram_LDFLAGS = $(top_srcdir)/libtestauto/libtestauto.la" which I changed at this point to "exampleProgram_LDFLAGS = $(top_builddir)/libtestauto/libtestauto.la" and then the terminal "make" ran straight to the end. CDT however refuses to try to run make. Every time I choose "Build Project" I get the same error.

Any ideas what is wrong?

My environment is Mac OS X 10.9.x and Eclipse Luna with CDT 8.4.0.201406111759 (all x86_64)
The JDK is Oracle 1.8.0_20 (again x86_64)

Update - here is the stack trace I found in the error log:

org.eclipse.core.internal.resources.ResourceException: A resource exists with a different case: '/test/Debug/Makefile'.
	at org.eclipse.core.internal.resources.Resource.checkDoesNotExist(Resource.java:329)
	at org.eclipse.core.internal.resources.Resource.checkDoesNotExist(Resource.java:307)
	at org.eclipse.core.internal.resources.File.create(File.java:112)
	at org.eclipse.core.internal.resources.File.create(File.java:188)
	at org.eclipse.cdt.managedbuilder.makegen.gnu.GnuMakefileGenerator.createFile(GnuMakefileGenerator.java:4340)
	at org.eclipse.cdt.managedbuilder.makegen.gnu.GnuMakefileGenerator.regenerateMakefiles(GnuMakefileGenerator.java:953)
	at org.eclipse.cdt.managedbuilder.internal.core.CommonBuilder.performMakefileGeneration(CommonBuilder.java:1006)
	at org.eclipse.cdt.managedbuilder.internal.core.CommonBuilder.performPrebuildGeneration(CommonBuilder.java:873)
	at org.eclipse.cdt.managedbuilder.internal.core.CommonBuilder.build(CommonBuilder.java:748)
	at org.eclipse.cdt.managedbuilder.internal.core.CommonBuilder.build(CommonBuilder.java:510)
	at org.eclipse.cdt.managedbuilder.internal.core.CommonBuilder.build(CommonBuilder.java:459)
	at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:734)
	at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
	at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:206)
	at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:246)
	at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:299)
	at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
	at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:302)
	at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:358)
	at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:381)
	at org.eclipse.core.internal.resources.Workspace.buildInternal(Workspace.java:496)
	at org.eclipse.core.internal.resources.Workspace.build(Workspace.java:415)
	at org.eclipse.ui.actions.BuildAction$1.runInWorkspace(BuildAction.java:305)
	at org.eclipse.core.internal.resources.InternalWorkspaceJob.run(InternalWorkspaceJob.java:38)
	at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)

[Updated on: Fri, 12 September 2014 20:23]

Report message to a moderator

Re: Out-of-source auto-tools build [message #1422362 is a reply to message #1422352] Fri, 12 September 2014 18:49 Go to previous messageGo to next message
Alex Mising name is currently offline Alex Mising nameFriend
Messages: 149
Registered: March 2010
Senior Member
I've just found out that my file-system is case-insesitive! (I'm also a new Mac user). Out of desperation I did "cat makefile.am" and it works (even though listing files with ls show it as Makefile.am)!

So Eclipse's complaint now makes sense to me. Apparently it checks for files like Makefile.am and makefile.am, finds both and shows this error. Is there any way around this?

Meanwhile, I'm looking to see if I can format my HDD with some other (case sensitive) file-system...
Re: Out-of-source auto-tools build [message #1422365 is a reply to message #1422362] Fri, 12 September 2014 18:52 Go to previous messageGo to next message
Alex Mising name is currently offline Alex Mising nameFriend
Messages: 149
Registered: March 2010
Senior Member
Yeah, looks like I need a re-install, or a new partition... http://superuser.com/questions/380330/mac-convert-from-case-sensitive-to-case-insensitive-file-system
icon8.gif  Re: Out-of-source auto-tools build [message #1422373 is a reply to message #1422365] Fri, 12 September 2014 19:08 Go to previous messageGo to next message
Alex Mising name is currently offline Alex Mising nameFriend
Messages: 149
Registered: March 2010
Senior Member
I have split my disk into two separate partitions. I formatted the new partition as case-sensitive. However, I still get the same error! Can anyone help? It'll be greatly appreciated...

My-MacBook-Pro:Debug user$ pwd
/Volumes/data/ws/adt-default/test/Debug
My-MacBook-Pro:Debug user$ ls makefile
ls: makefile: No such file or directory
My-MacBook-Pro:Debug user$ ls Makefile
Makefile


It appears that the case-sensitivity of HFS is not a factor:

1. I get the same error even in a case-sensitive partition.
2. As mentioned in the original question, the build works even in a case-INsensitive partition, as long as I don't use a separate build directory and build alongside the sources.

I have found the stack trace in the (edited original question to add it) and it seems like the org.eclipse.cdt.managedbuilder code is being invoked and trying to generate a Makefile. I am pretty sure this is wrong: I am using autotools to generate the Makefile. This seems like suddenly my project has switched to a "Managed Project" type (the custom CDT type). Should I open a bug report maybe?

[Updated on: Fri, 12 September 2014 20:01]

Report message to a moderator

Re: Out-of-source auto-tools build [message #1422407 is a reply to message #1422373] Fri, 12 September 2014 20:22 Go to previous message
Alex Mising name is currently offline Alex Mising nameFriend
Messages: 149
Registered: March 2010
Senior Member
I have finally made a break-through.

I removed the build configuration which was broken, as it seems to me now that "Shared Library -> MacOSX GCC -> Debug" probably means switching to the managed project builder.

I then created a new build configuration called "Debug2" and copied the settings from the working "Build (GNU)" one that was generated by the wizard. In the "C/C++ Build" page of the project properties I set the "Build directory" to "${workspace_loc:/test}/Debug". Then in the "C/C++ Build -> Environment" page I defined my "CFLAGS=-g3 -O0" setting. I made this configuration active and now everything finally works as expected...
Previous Topic:Auto generate dependencies
Next Topic:Eclipse+SDCC - java.lang.NullPointerException error when creating new project
Goto Forum:
  


Current Time: Fri Apr 26 15:35:16 GMT 2024

Powered by FUDForum. Page generated in 0.04317 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top