strange behavior with makefile

classic Classic list List threaded Threaded
5 messages Options
Uwe
Reply | Threaded
Open this post in threaded view
|

strange behavior with makefile

Uwe
Hi,

I am just before getting mad with that makefile. I already shortened my large makefile to just a few lines:

makefile:

TARGET = TEST

SRC_DIR   = ..\src
OUT_DIR   = ..\out
TMP_DIR   = ..\tmp

vpath %.c $(SRC_DIR)
       
# Compiler
CC = ..\..\tools\compiler\cx6808
       
CFLAGS = -pp -vl +nowiden +debug -oc -co$(TMP_DIR) -cl$(OUT_DIR)

C_FILES_APP = bootload.c can.c

H_FILES_APP = bootload.h

OBJ_FILES = $(C_FILES_APP:.c=.o)


FIRST: $(TARGET).s19


all: h08 s19

h08: $(TARGET).h08
s19: $(TARGET).s19

$(TARGET).h08: $(OBJ_FILES)



Call from command shell:
..\..\tools\make\make -n -s -f makefile all


Output:
..\..\tools\compiler\cx6808 -pp -vl +nowiden +debug -oc -co..\tmp -cl..\out   -c -o bootload.o ..\src/bootload.c
..\..\tools\compiler\cx6808 -pp -vl +nowiden +debug -oc -co..\tmp -cl..\out   -c -o can.o ..\src/can.c
make: *** No rule to make target `TEST.s19', needed by `s19'.  Stop.



Why does make indicate that it wants to make a compiler call and why with those options -c -o and why is there a / instead of a \ ???

Can anybody help me?

Thank you!

Uwe
Reply | Threaded
Open this post in threaded view
|

Re: strange behavior with makefile

Paul Smith-20
On Mon, 2014-01-20 at 00:45 -0800, Uwe wrote:
> I am just before getting mad with that makefile. I already shortened my
> large makefile to just a few lines:

> SRC_DIR   = ..\src
> OUT_DIR   = ..\out
> TMP_DIR   = ..\tmp

> # Compiler
> CC = ..\..\tools\compiler\cx6808
> CFLAGS = -pp -vl +nowiden +debug -oc -co$(TMP_DIR) -cl$(OUT_DIR)
>
> C_FILES_APP = bootload.c can.c
> OBJ_FILES = $(C_FILES_APP:.c=.o)
>
> all: h08 s19
>
> h08: $(TARGET).h08
> s19: $(TARGET).s19
>
> $(TARGET).h08: $(OBJ_FILES)
>
> *Call from command shell:*
> ..\..\tools\make\make -n -s -f makefile all

So, here you've asked make to build the "all" target.  make sees that to
do that it needs to build the "h08" target.  To do that it needs to
build the "$(TARGET).h08" target.  To do THAT it needs to build the
"bootload.o" and "can.o" targets.

Then it looks for a rule that can build these targets.  There are no
rules defined in your makefile that specify how to build a .o file, so
make uses the built-in rule for compiling a .o from a .c, which is this
(use "make -pf- <nul" to see a complete list of built-in rules):

  %.o: %.c
          $(COMPILE.c) $(OUTPUT_OPTION) $<

where "COMPILE.c" is "$(CC) $(CFLAGS) $(CPPFLAGS) $(TARGET_ARCH) -c" and
"OUTPUT_OPTION" is "-o $@".

> *Output:*
> ..\..\tools\compiler\cx6808 -pp -vl +nowiden +debug -oc -co..\tmp -cl..\out  
> -c -o bootload.o ..\src/bootload.c
> ..\..\tools\compiler\cx6808 -pp -vl +nowiden +debug -oc -co..\tmp -cl..\out  
> -c -o can.o ..\src/can.c
> make: *** No rule to make target `TEST.s19', needed by `s19'.  Stop.
>
> Why does make indicate that it wants to make a compiler call and why with
> those options -c -o and why is there a / instead of a \ ???

The above explains why the compiler is called: because you've asked make
to build a .o file.

In your makefile you've set CC and CFLAGS, so that's where those values
come from.  You can see where the -o and -c come from: the default
rules.  If that's not the correct set of operations for your compiler,
you need to either define your own pattern rule, or if you want to use
the default rule you need to reset the COMPILE.c variable to contain the
command you want to use.

As for why the "/" instead of "\", make is a POSIX tool and it deals
with "/" as a directory separator.  The Windows port of make has some
facilities to read Windows paths instead, but when make constructs a
pathname (as it does here as a result of vpath) it will always use "/"
as the directory separator.

However, almost all Windows commands accept both "\" and "/" as
directory separators, so usually this is not a problem.


_______________________________________________
Make-w32 mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/make-w32
Uwe
Reply | Threaded
Open this post in threaded view
|

Re: strange behavior with makefile

Uwe
In reply to this post by Uwe
I found a quite simple solution:

call make with the -R Option which suppresses all built-in stuff ...
Reply | Threaded
Open this post in threaded view
|

Re: strange behavior with makefile

Eli Zaretskii
In reply to this post by Paul Smith-20
> From: Paul Smith <[hidden email]>
> Date: Mon, 20 Jan 2014 08:17:43 -0500
> Cc: [hidden email]
>
> As for why the "/" instead of "\", make is a POSIX tool and it deals
> with "/" as a directory separator.  The Windows port of make has some
> facilities to read Windows paths instead, but when make constructs a
> pathname (as it does here as a result of vpath) it will always use "/"
> as the directory separator.
>
> However, almost all Windows commands accept both "\" and "/" as
> directory separators, so usually this is not a problem.

Indeed.  And if some tool does care, just take the argument in quotes,
and it won't.

_______________________________________________
Make-w32 mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/make-w32
Reply | Threaded
Open this post in threaded view
|

Re: strange behavior with makefile

Paul Smith-20
In reply to this post by Uwe
On Mon, 2014-01-20 at 07:06 -0800, Uwe wrote:
> I found a quite simple solution:
>
> call make with the -R Option which suppresses all built-in stuff ...

That can't be a valid solution, given the makefile you provided before.

If you suppress the built-in rules then there will be no rules that know
how to build files like "bootload.o", and if the "bootload.o" file does
not exist then your makefile will fail saying that there is no rule to
build that file.

If you provide your own rule that knows how to build files like
"bootload.o" then it will always take precedence over the built-in rules
anyway so using or not using -R makes no difference.


What I suspect has happened is that you've gotten "bootload.o" and
"can.o" compiled some other way and so those files now exist; when you
run "make -R" it succeeds because they don't need to be rebuilt.

If you were to delete those object files and start the build from
scratch using the "-R" flag, you will get an error saying make doesn't
know how to build those files.


If that's not the case, then the makefile example you provided to us is
so unrepresentative of your actual environment that there's no way we
can provide advice.


_______________________________________________
Make-w32 mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/make-w32