Version: 3.0.0b2 (using KDE KDE 3.2.0) Installed from: Debian stable Packages Related bugs are http://bugs.kde.org/show_bug.cgi?id=34964 http://bugs.kde.org/show_bug.cgi?id=71675 http://bugs.kde.org/show_bug.cgi?id=74570 The problem is that I get this error-message pressing F8, on an imported kmail subdir from the kdepim package: |There is no Makefile in this directory |and no configure script for this project. |Run automake & friends and configure first? Now, this message is totally bogus, because: - I already ran configure, which is in the parent-dir - there _is_ a Makefile in the project root - 'this directory' is totally useless information ); - there is no requirement for any hardcoded makefile filenames at all. The patch from 74570 to add one more name is only half-hearted, as 71675 clearly shows. Anyone who tried to use a different build-system like jam/bjam to build anything will confirm that. - make itself will already generate sufficient error-messages when it fails to find its files Please remove the whole check or make it a warning, in the latter case one with a checkbox to permanently disable it. As a workaround for all bitten by this, you can add an entry to the external tools for a file context with - Menu text = make - Executable = make - Parameters = -C %D -f %S - a checked 'capture output' Note: clicking on an error-message doesn't work with that. thank you Uli
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. ***