The infamous "No rule to make target" problem
Matt Osminer
problem. As any Tornado sufferer will tell you the solution should be
1. Add -I directives to your C/C++ settings
2. Add a VPATH directive to your makefile Macros from the Project Macros Tab
3. Rebuild all dependencies, then Build-All
Wondering if anybody has tried all of the above, as I have, and still been
unable to get past the "No rule" error? My project was working just fine
and then I did the unthinkable act of removing a few obsolete files and
adding some new files. I didn't touch the -I or VPATH configurations and my
new files all fell within the bounds of the original settings so there
shouldn't have been a problem.
The weird thing is Tornado just seems to be having a hard time locating this
one directory. All my other -I directories appear just fine.
I've tried:
1. Closing Tornado, rebuilding dependencies, saving the workspace, and
"building-all" in about every combination you can think of.
2. Removing all the -I options and re-entering them
3. Removing the VPATH and re-entering it
4. Checked for directory existance etc.
Any further ideas out there???
taa...@sandia.gov
I'm sorry to say that I too have encountered this problem. In fact I
reported it to Wind River's tech support. They were unable to reproduce
the problem and demanded all of my files. Due to various reasons, this
is simply out of the question and the support stalled right there.
The only solution I found was to delete the entire project and recreate
it from scratch. I've now had to do this three times now, and I'm
getting rather sick of it.
I've only seen this problem in Tornado version 2.1 for the PPC.
The problem appears to be that dependencies are not being regenerated
after deleting old files and then adding new files. For instance, I
can delete a file from the project named pmcsio4.cpp, then add a file
named serial.cpp. I then hit the "Update Dependencies" button.
Then I exit Tornado and hit "Yes" when asked whether or not
to save the workspace.
At this point when I take a look at the makefile and the .prj file,
they both still have references to the old file (pmcsio4.cpp) and no
mention of the new file (serial.cpp).
I didn't have this problem with earlier versions of Tornado (2.0, 1.x).
If you find out any way of working around this problem, please let
us know.
Tad Ashlock <taa...@sandia.gov>
Bill Pringlemeir
[snip]
Tad> At this point when I take a look at the makefile and the .prj
Tad> file, they both still have references to the old file
Tad> (pmcsio4.cpp) and no mention of the new file (serial.cpp).
Tad> I didn't have this problem with earlier versions of Tornado
Tad> (2.0, 1.x).
Tad> If you find out any way of working around this problem, please
Tad> let us know.
I am not sure if I know about this problem.
"http://www.xs4all.nl/~borkhuis/vxworks/vxw_pt1.html#1.6-B"
"http://www.xs4all.nl/~borkhuis/vxworks/vxw_pt1.html#1.7-C"
In our projects we have more than one target. Often I get what is
being discussed, or so I believe. Changing the build target and
updating dependacies seems to solve this.
The "wpj" is just a list of information that a TCL script reads and
uses to produce the make file. The "makeGen.tcl" in Johan's FAQ uses
these TCL files. There are also some other Tornado files for doing
command line builds. I filed a TSR about this and it is fairly
complex to set up, but it does work. The file comments have some
statements that aren't quite right. For example,
"/Tornado/host/resource/tcl/app-config/Project/cmpScriptLib.tcl"
Not sure if this is the actual files I was looking at... I just ended
up using a modified version of "makeGen.tcl" to produce lint rules and
emacs ebrowse files.
hth,
Bill Pringlemeir.
--
CESID CIDA 2600 Magazine secure Skipjack basement halcon PLO Rule Psix
USDOJ UOP Sears Tower RSA supercomputer INSCOM AES crack
Michael R. Kesti
I've had luck removing the offending file from the project and again
adding it. This sometimes turns into "gopher smashing", as fixing one
file seems to cause another to fail. Perseverence usually pays off,
however, and I eventually get the system back to the state where it
will again build.
--
========================================================================
Michael Kesti | "And like, one and one don't make
| two, one and one make one."
mke...@gv.net | - The Who, Bargain
Graham Baxter
--
Regards,
Graham Baxter
Freelance Software Engineer (VxWorks and pSOS BSPs)
Graham Baxter (Software) Limited
gba...@NOSPAMbcs.org.uk
"Matt Osminer" <mosm...@vantum.com> wrote in message
news:3db57e4b$2...@news.mhogaming.com...
joe durusau
GUI for building things, and use the makefile that comes in the BSP
directory. You copy all the files you need into a single directory,
gen up MACH_EXTRA (IIRC, not sure of the exact spelling),
and away you go! You have to wean everybody away from
the idea of having to click on something, but this method
generally always works. I generally use sccs, and stick the makefile in
sccs along with all the sources and suchlike.
Speaking only for myself,
Joe Durusau
Emmanuel Herbreteau
Same problem : our Tornado project began to crash with
the "no rule to make target" message. A close look at
the generated makefile show the following lines :
.../...
$(PRJ_DIR)/programmation/instructionTimer.hpp \
$(PRJ_DIR)/programmation/ModifValeur.hpp \
$(PRJ_DIR)/programmation/clavierPLC.hpp \
{Tornado \
argetconfig sp823define_can.h} \
$(PRJ_DIR)/ihm2/FenetreManuel.hpp \
$(PRJ_DIR)/ihm2/FenetreRangement.hpp \
.../...
This kind of error appears several times in the makefile.
Obviously, there is a nasty bug in the makefile generator...
(Tornado 2.0.2 CP4 PPC).
It appears sometime when we try to add/remove a file in
our project or when we try to check the dependencies.
(80 files in our project)
Then, to restore our project, we have to get the project
file from our backup.
WRS support just told us : "you have to buy the new Sniff
project manager, which is, of course, much better than Tornado"...
(Your car broke down ? Just buy a new car !)
Funny, isn't it ? >8-(
Regards
Emmanuel
Matt Osminer wrote:
> I seem to have come to an impasse with the infamous "No rule to make target"
> problem. As any Tornado sufferer will tell you the solution should be
.../...
Jakob Olsen
We have run extensive research into this problem in the company I am working
in.
Here's a few tips:
1. Always use forward slashes in -I directives. use /target/h not \target\h.
2. Remove the "-I." that Tornado adds to projects automatically, and which
does searches in the "current directory" that can be pretty undefined.
3. Make sure that the file extension of all included files is lowercase (
foo.h not foo.H ). TOrnado has a bad habit of just ignoring files with
uppercase extensions.
Following these rules very strictly has eliminated the problem in all our
projects.
Try it out.
Jakob
"Matt Osminer" <mosm...@vantum.com> wrote in message
news:3db57e4b$2...@news.mhogaming.com...
Red Fenris
> Any further ideas out there???
>
Yes - forget about the infamous Tornado and make your own makefiles from
those producted by the tcl environment
Speaking for myself only
-------------------------------------
Support third world debt cancellation
and reduction of military spendings
-------------------------------------
Andreas Bachmeier
wrote:
>3. Make sure that the file extension of all included files is lowercase (
>foo.h not foo.H ). TOrnado has a bad habit of just ignoring files with
>uppercase extensions.
That's right. I also run in this problem. But you also have to have a
look at the c-files. Upper extension (foo.c not foo.C) is also a
problem for Tornado.
Andreas
taa...@sandia.gov
> [snip]
>
> Tad> At this point when I take a look at the makefile and the .prj
> Tad> file, they both still have references to the old file
> Tad> (pmcsio4.cpp) and no mention of the new file (serial.cpp).
>
> Tad> I didn't have this problem with earlier versions of Tornado
> Tad> (2.0, 1.x).
>
> Tad> If you find out any way of working around this problem, please
> Tad> let us know.
>
> I am not sure if I know about this problem.
>
> "http://www.xs4all.nl/~borkhuis/vxworks/vxw_pt1.html#1.6-B"
> "http://www.xs4all.nl/~borkhuis/vxworks/vxw_pt1.html#1.7-C"
I tried the makeGen.tcl script and it generated a makefile identical
to the one in my project. I suspect that this is due to the .prj
file not having the dependencies in the first place. Pushing the
"Update Dependencies" button in the Tornado IDE doesn't even
generate a new .prj file (i.e. the file time doesn't change).
> In our projects we have more than one target. Often I get what is
> being discussed, or so I believe. Changing the build target and
> updating dependacies seems to solve this.
Tried this and it didn't change anything.
> The "wpj" is just a list of information that a TCL script reads and
> uses to produce the make file. The "makeGen.tcl" in Johan's FAQ uses
> these TCL files. There are also some other Tornado files for doing
> command line builds. I filed a TSR about this and it is fairly
> complex to set up, but it does work. The file comments have some
> statements that aren't quite right. For example,
>
> "/Tornado/host/resource/tcl/app-config/Project/cmpScriptLib.tcl"
>
> Not sure if this is the actual files I was looking at... I just ended
> up using a modified version of "makeGen.tcl" to produce lint rules and
> emacs ebrowse files.
>
> hth,
> Bill Pringlemeir.
> --
> CESID CIDA 2600 Magazine secure Skipjack basement halcon PLO Rule Psix
> USDOJ UOP Sears Tower RSA supercomputer INSCOM AES crack
Thank you Bill for trying to help.
Tad
taa...@sandia.gov
I don't know if this will help the OP, but I discovered what
was causing *my* problem. It turns out that the problem only
occurs when I put "-x c++" (without the quotes, of course)
in the C/C++ Compiler build parameters (what gets put into
the makefile as CFLAGS).
I don't remember why I added the "-x c++" (used to override
gcc's automatic file-type detection) to the build parameters.
Taking it out didn't seem to have any effect on the output
of the compiler.
I can't think of a good reason that this compiler flag should
cause the behavior I'm seeing with the re-generation of
dependencies. So I'm planning on submitting this as a bug to
Wind River.
Tad
franco spadafora
2. Give up and write a Makefile. If you don't need to play around on a
regular basis with the vxWorks libraries and project settings, there is not
much advantage to using the GUI.
"Matt Osminer" <mosm...@vantum.com> wrote in message
news:3db57e4b$2...@news.mhogaming.com...
Robotz
Well I just ran into the problem too on Tornado 2.02 working with a
PPC. I finally managed to fix it by changing two things:
1) I replaced the "-I." with "-I$(PRJ_DIR)" which you can do in the
build settings.
2) I had to fix a problem in the dependencies section. Tornado
generated the following in the Makefile...
## dependencies
sensor.o: $(PRJ_DIR)/sensor.c ethernet.h
....and I had to change it to....
## dependencies
sensor.o: $(PRJ_DIR)/sensor.c $(PRJ_DIR)/ethernet.h
...which worked. But it seems like every time I do something that
causes it to generate a Makefile, it screws this part up again and I
don't know of a way to fix it other than to edit the Makefile each
time. I tried generating dependencies again after I manually fixed it
and then it generated....
## dependencies
sensor.o: $(PRJ_DIR)/sensor.c {$(PRJ_DIR)/ethernet.h}
...so I don't know what it thinks it's doing.
I noticed some people saying that their Makefile wasn't changing after
they updated dependencies or added files etc. I found that if you do
something that should trigger a Makefile update, it doesn't actually
update the Makefile until you build.
And I'm no expert on Makefiles so if you notice any mistakes, please
let me know.
-Paul