Community
Participate
Working Groups
Build Identifier: Indigo It can't find "binary" if you put any dot in the project name. Any moment you delete the dot and recompile it finds the "binary" when running. Reproducible: Always Steps to Reproduce: 1. Put a dot in the name of the project 2. Try to execute
What language/editor are you using? What steps are you doing to "execute"? PW
(In reply to comment #1) > What language/editor are you using? What steps are you doing to "execute"? > > PW We, at the Malaga (Spain) University, use C/C++ (downloaded Indigo version with this plugin installed) in the MacOSX Snow Leopard (Eclipse 3.7 for Mac OS X). JF
Can you see the binary under "Binaries" in the Project Explorer? Sorry, I would try it myself but I don't have access to a Mac right now. I tried to create a project 'test.dot' on Windows and it correctly built and debugged the 'test.dot.exe' executable.
(In reply to comment #3) > Can you see the binary under "Binaries" in the Project Explorer? Sorry, I would > try it myself but I don't have access to a Mac right now. I tried to create a > project 'test.dot' on Windows and it correctly built and debugged the > 'test.dot.exe' executable. I also did, of course, and in Linux Ubuntu, and it all worked… The bug is only in the Mac version (any) of Eclipse C/C++
Created attachment 209513 [details] Parse binaries with project name (In reply to comment #4) > (In reply to comment #3) > > Can you see the binary under "Binaries" in the Project Explorer? Sorry, I would > > try it myself but I don't have access to a Mac right now. I tried to create a > > project 'test.dot' on Windows and it correctly built and debugged the > > 'test.dot.exe' executable. > > I also did, of course, and in Linux Ubuntu, and it all worked… The bug is only > in the Mac version (any) of Eclipse C/C++ What name did you try on Ubuntu? I tried test.dot and it didn't work. The reason it worked for me on Windows is that the binary becomes test.dot.exe and files with the extension .exe are defined as binaries in the Content Types (Preferences, General, Content Types). The binary is not being found because of an optimization: // Only if file has no extension, has an extension that is an integer // or is a binary file content type If those conditions are met, then the file is parsed to determine whether or not it's a binary. I'm not sure we can do much to improve that. Some options: 1. Check if the file name is equal to the project name, if so parse it. That's weak since the artifact can be renamed in the project properties. But it would still be a tiny improvement. 2. Augment the CModel so that it knows about the generated artifacts. That solves the case where the artifact is being renamed in the project properties but it would still fail if it's being renamed manually or generated from an external builder like Make. I think this would be too much work for a still imperfect solution. I did option 1 in my patch, but really, I'm not sure it's worth it since this only fixes the case where projectName == binaryName.
Markus, I believe you have some experience with CModelManager and binary parsing performance (bug 194194). Do you have an opinion on the issue?
(In reply to comment #6) > Markus, I believe you have some experience with CModelManager and binary > parsing performance (bug 194194). Do you have an opinion on the issue? Testing all files with the binary parser is too slow, therefore we limited the check to files that have a known extension (*.so, *.exe, ...) or no extension. On Unix systems you really want to check the executable flag of the file, it may be performant enough to do that on every file in the project. If not we should not do it and option 1 would be a good improvement.
*** Bug 375342 has been marked as a duplicate of this bug. ***
(In reply to comment #5) > 2. Augment the CModel so that it knows about the generated artifacts. That > solves the case where the artifact is being renamed in the project > properties but it would still fail if it's being renamed manually or > generated from an external builder like Make. I think this would be too much > work for a still imperfect solution. There was a user reporting such a problem in the CDT forum http://www.eclipse.org/forums/index.php/m/1065534/#msg_1065534 The ManagedBuilder should quite precisely know which artifacts it builds. The performance optimization is OK (and necessary) for Makefile builds.
