Re: [cc65] THE Makefile V1.2 available - was: automatic generation of makefile dependencies

Hi,

>>> Anyway, the quick fix for me for now is to just drop the "-p" switch
>>> from the command. Just wanted to let you know if you want to add
>>> Windows compatibility some day.

The -p switch is actually necessary.

"Windows compatibility" is an interesting term here. The Makefile
requires GNU make which isn't part of Windows so the Makefile is
intrinsically not Windows compatible.

Rather you need additional software to use the Makefile on Windows -
and if you install the right software, it'll work on Windows (i.e. I
run Windows exclusively) so it's Winmdows compatible from that
perspective.

>> So I just renamed the UnxUtils mkdir to
>> mkdir2 and ...

I evaluated about all "Unix Tools on Windows" solutions at work in
quite some detail - and from that exeperience I recommend to stay
clear from UnxUtils.

> My best guess is that cygwin is the common environment under
> Windows for this type of development, and there forward slashes
> are actually allowed.

I've been developing/testing the Makefile with Cygwin and so - not
surprisingly at all - it works in that environment.

However one might consider Cygwin somewhat ;-) heavyweight just for
using that Makefile. The only lightweight "Unix Tools on Windows"
solution that is actually worth considering is GnuWin32
(http://gnuwin32.sourceforge.net/). GunWin32 is especially the only
non-Cygwin solution providing a reasonably recent GNU make.

I haven't however tested the Makefile with GunWin32 so far, maybe
someone else...

BTW: There's a scenario where GnuWin32 is even superior to Cygwin:

Cygwin tries very hard to make non-Cygwin programs work nicely in the
Cygwin environment - i.e. regarding pathnames. So every commandline
parameter and all environment variables looking like they contain a
(Cygwin-)pathname are converted to a Win32-pathname for the called
program. As cl65.exe is a non-Cgywin program all these mechanisms are
active, usefull and necessary. However when pathnames are i.e.
embedded in files Cygwin can't do it's magic on them. And exactly this
happens in our scenario. The cc65 compiler writes the dependency files
(of course) using Win32-pathnames. But then the Cygwin GNU make tries
to read them as Cygwin-pathnames :-(

For the Makefile discussed here this is no issue because Uz
implemented a change that I suggested to him because of the problem
pointed out above. The cc65 compiler now only places dependencies in
the dependency files that are not system header files. If you develop
a cc65 user program you're not fiddling with the cc65 header files. So
omitting them is generally correct and improves performance - even if
not significant in practise.

The Makefile discussed here places all sources in subdirectories so
the cc65 compiler uses relative pathnames in the generated dependency
files. And relative pathnames (with forward slashes) are compatible
between Win32 and Cygwin. As you see the ice you're walking on is
quite thin - even if you typically don't notice ;-))

However if you're building i.e. a 3rd party Contiki application than
you usually end up with absolute pathnames in your dependency files
and then GnuWin32 works better because its GNU make is a native Win32
program which understands the Win32-pathnames in the dependency files
written by the native Win32 cc65 compiler. Addionally the GNU make
source contains quite some hacks/tricks/workarounds to better get
along with Win32 pathnames. These code parts are - logically - not
activated in the Cygwin build of GNU make. Therefore I'm in general
using Cygwin less and less for cc65 builds...

Have fun,
Oliver
----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo@musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.