Bug 76012 - bogus report that it fails to find makefile
Summary: bogus report that it fails to find makefile
Alias: None
Product: kdevelop
Classification: Applications
Component: Build tools: Automake (show other bugs)
Version: 3.0.0b2
Platform: Debian stable Linux
: NOR normal
Target Milestone: ---
Assignee: KDevelop Developers
: 102409 (view as bug list)
Depends on:
Reported: 2004-02-24 13:27 UTC by Ulrich Eckhardt
Modified: 2006-12-07 21:51 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Note You need to log in before you can comment on or make changes to this bug.
Description Ulrich Eckhardt 2004-02-24 13:27:48 UTC
Version:           3.0.0b2 (using KDE KDE 3.2.0)
Installed from:    Debian stable Packages

Related bugs are 

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

Comment 1 cryst 2004-03-04 06:52:51 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?)
Comment 2 cryst 2004-03-05 06:06:22 UTC
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
Comment 3 cryst 2004-03-05 06:19:47 UTC
A new hint.  Switching project configuration to default compiles fine. Switching to debug or optimized can't find the makefile.
Comment 4 Amilcar do Carmo Lucas 2004-03-05 09:01:09 UTC
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.
Comment 5 cryst 2004-03-06 05:36:20 UTC
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.
Comment 6 cryst 2004-03-06 06:26:44 UTC
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).

Comment 7 Amilcar do Carmo Lucas 2004-03-06 15:05:39 UTC
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.
Comment 8 Jens Dagerbo 2004-03-06 15:36:59 UTC
It's a pity this discussion ended up here, because this is NOT the issue reported in the bug!
Comment 9 cryst 2004-03-06 20:13:42 UTC
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).
Comment 10 Jens Dagerbo 2004-03-06 20:38:21 UTC
>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.
Comment 11 Thomas McGuire 2006-12-05 21:27:36 UTC
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.
- 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
Comment 12 Megan Webb 2006-12-07 20:39:49 UTC
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.
Comment 13 Megan Webb 2006-12-07 21:51:30 UTC
*** Bug 102409 has been marked as a duplicate of this bug. ***