Unsolved error: No rule to make target - how to troubleshhot
-
error: No rule to make target - how to troubleshot
I am asking for comments on how to troubleshot this issue,I have added new dialog and it did what I expected .
I did not like the name so I used "find and replace " it in the retire project.
I changed "TempTaskDialog" to "ConfigureTaskDialog".The build failed with this error :
:-1: error: No rule to make target 'ConfigureTaskDialog.ui', needed by 'ui_ConfigureTaskDialog.h'. Stop.
The error did not identify WHERE IS THE problem - as it generally does.
Asked Mrs Google and she came up with similar problem "solution" , however , the solution seems to mask the real issue - what is a cause of the "no rule to make a target " and specifically what did my "find a replace" missed and where.
I am asking for generic comments on the issue - I can eventually find out what is missing and where, irregardless of the sketchy error posted by build process.
-
@AnneRanch said in error: No rule to make target - how to troubleshhot:
The error did not identify WHERE IS THE problem - as it generally does.
It does exactly say what's wrong:
No rule to make target 'ConfigureTaskDialog.ui'
As you can see it can't find or don't know how to create this file.
-
Hi
The UI file itself also contains the class name. ( the dialog name in this case)
So double click the UI file and make sure its name also changed in the top.
-
@mrjj said in error: No rule to make target - how to troubleshhot:
Hi
The UI file itself also contains the class name. ( the dialog name in this case)
So double click the UI file and make sure its name also changed in the top.
Thanks for the reply,
I am not sure what is happening but after "find and replace" I do not even have the former files in "Projects" .So - no original files and n0 renamed files - as far as "project" is concerned.
Unfortunately I did no back up my project before doing the "find and replace".
But my common "include " header does not complain -it "sees" the newly named files .
//added copy of orignal taskdialog
#include <QProgressDialog>
#include "ConfigureTaskDialog.h"
#include "ui_ConfigureTaskDialog.h"It looks as the "build" process error does indeed "stops" and does not have chance to report the missing files.
Instead of looking for reason why it failed - I''l by[pass all "new stuff" then I'll add another "configuration" dialog , compile it and then hopefully I can guess better what the problem was /is.
-
@AnneRanch
Hi
Ok that is a bit odd if the files actually vanished from the project file.
Its a good plan to simply recreate the dialog. that should surely work and
also add the files to the project again.If you again feel like rename something, i suggest using the refactor menu
Right click on the name you want to change and it show show in menu.
It will then show what will be changed.
This is slightly safer than normal search and replace as its aware of the type and will not try to replace anything
that just has part of the name or similar. -
@mrjj Funny , after a short break I came to same conclusion.
It is hard to believe that "simple" rename would cause such disaster - actually deleting the entire files from the project.
Lesson learn. -
@AnneRanch
Hi
Yes that puzzles me to as normally rename might "only" break the project
a bit and not make files go missing.
But rename classes with UI files is not optimal so I normally think a moment extra when naming new
dialogs / widgets as I have also had a few cases where it kept on being unhappy.I also managed with search and replace to alter some of Qt own .h files of cause totally broke it :)
So now i check which files will be affected very carefully :) -
@mrjj
There is one big "gotcha" here . I recall form my early days of programing that it was common to build a separate project to test the idea without having to keep recompiling the whole main project. After all that is what "subroutines" were used for.Adding the finished "subroutine / function " to the main project frequently required renaming few variables , mainly to avoid name conflicts.
That was few years back and it appears that such approach is no longer "normal", hence the coder's life is actually harder then 40 years ago.
Yes, I could have renamed the code before adding it to my main project, but even that is a poor excuse for the way "find and replace" works in Qt.
I was actually trying to implement "main project -> sub project(s) " and it did not get started well. But that would be overkill anyway ...maybe later.