| Summary: | bogus report that it fails to find makefile | ||
|---|---|---|---|
| Product: | [Applications] kdevelop | Reporter: | Ulrich Eckhardt <doomster> |
| Component: | Build tools: Automake | Assignee: | KDevelop Developers <kdevelop-devel> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | wcancino |
| Priority: | NOR | ||
| Version: | 3.0.0b2 | ||
| Target Milestone: | --- | ||
| Platform: | Debian stable | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Ulrich Eckhardt
2004-02-24 13:27:48 UTC
I get the same problem on a project where the configure and Makefiles were originally made with 3.0 (and are present). The message is confusing, because there is a makefile in the project directory and the message doesn't say what directory it's talking bout. (sources?) This is a bad bug, (a blocker!) I can't work with this system if I can't make. Please look into this. Thanks, Chris A new hint. Switching project configuration to default compiles fine. Switching to debug or optimized can't find the makefile. NEVER: Use the default configuration if you want to later use one of the debug or optimized configuration. The default breaks the other two. Solution1: NEVER use the default configuration, use only the other two. Solution2: ONLY use the default configuration. This is explained somewere. I think this is a dupe. But I do not have the time to check it now. Thank you for your comments. 1. At this point, switching to default, optimize or debug doesn't work. They are all broken. 2. Your solutions are not solutions to a problem, they are solutions to avoiding a problem. This leads me to believe that my only solution is to rebuild the project. (I hate that solution!) 3. I can't believe that this was designed in. At the least, if it was the intended design, once one option set had been selected, the other should have been disabled. This is a flaw in the program, and should not be written off. For other souls out there who are pulling their hair out trying to get configure to work, try deleting config.status It seems to interfere with configure (need to run distclean, which doesn't clean config.status as far as I can see). Cryst: About your #5 comment: 1. yes they are. 2. Yes you need to rebuild. 3. you are rigth, It is a bug, but at this point the developers are concentrated on other issues. It's a pity this discussion ended up here, because this is NOT the issue reported in the bug! It's all related. The bogus Makefile error shows up because of the default/optimize/debug problem. The (temporary) solution that I found (without rebuilding the project) is to delete config.status, which will relieve the deadlock situation and allow configure. (back from default to debug). >It's all related. Not really, unless you consider all automake issues related. Even if you do, it's still no reason to cram several problems into one bugreport. >The bogus Makefile error shows up because of the default/optimize/debug problem. No and no. In your case, but not in the reported case, the multiple build configuration problem is the cause of the Makefile warning. In your case however, it is NOT bogus - there IS no makefile for the configuration you have switched to, so it needs to be created. It cannot be created due to the "multiple build configuration problem", but this is clearly not the reported problem. As for the 'config.status' file. I came to the same conclusion as you last time I looked at this, but got conflicting reports from other users. Apparently, removing that file isn't always enough. I never got further with the problem and hoped the smart kids that came up with this system would figure it out. Still, it appears to me to be a bug of the distclean target to not remove 'config.status'. It's a generated file and as such I assume it should be cleaned up. I also experienced the "default/optimize/debug problem", it took me some time to figure out what the cause/workaround was.
I did everything from within the automake manager in KDevelop, since it does not work, it is clearly a bug.
How to reproduce:
0. Start KDevelop, close all existing projects
1. Project->New Project...->C++->Simple Hello world program
2. Use "test" as Application name
3. Click "Next" several times
4. Build->Build Project->Run Them
5. On the automake manager tab, right-click src->Add new subproject...
6. Use "foo" as subproject name, then click OK
7. Expand "src" in the tree, right-click foo->Add Target...
8. Use "bar" as file name, then click OK
9. Right click "bar (Program in bin)"->Create New File...
10. Use "foobar" as filename, select "C++ Source", then click OK
11. Ignore message by clicking OK
12. Left-click foobar.cpp so it opens in editor
13. Add main() {return 0;} at the end of the file in the editor
14. Right-click "bar (Program in bin)"->Build Target->Run Them
15. Right-click "bar (Program in bin)"->Execute target
16. The messagebox which is shown now ("There is no Makefile in this directory [..]" should not be shown. It is impossible to start "bar". Clicking any button on that messagebox does not do anything and even brings up that dialog again many times in a row (up to 5 times)
The messagebox is also shown sometimes when building a target.
This seems to be a problem with the build configuration.
Switching to Project->Build Configuration->default solves the problem.
However:
- The average user does not know this. Because of this, I consider this bug serious, because the automake manager simply does not work for the average user
- It is not possible to use multiple build configurations anymore
So please fix the automake manager to work with all build configurations.
This is with KDevelop 3.4 SVN 2006-12-05
Thanks for the detailed reproduce steps Thomas McGuire. They made all the difference in looking at this issue. Committed revision 611280 to 3.4 branch. autoprojectpart.cpp autoprojectpart.h *** Bug 102409 has been marked as a duplicate of this bug. *** |