Xen devel - May 2006 - CFLAGS are for C compilers and other Unix traditions

I recognize the vitality of youth, but please allow me to plug some
Unix traditions.  There is a long tradition on how to write
makefiles.  Many of these traditions are encoded in the default rules
that are part of GNU make.  You can see them with the command:

$ make -p

If you execute this command, you will note that the rule for
assembling .S files is:

COMPILE.S = $(CC) $(ASFLAGS) $(CPPFLAGS) $(TARGET_MACH) -c

Note that you don''t give the assembler CFLAGS.  It''s not a C
compiler.

The default rules use TARGET_MACH in a very well thought out way.
Please use TARGET_MACH in a manor consistent with GNU make''s default
rules. 

Another long standing Unix tradition is that applications do not
depend on the path environment variable currently in effect.  Relying
on a path means that a user of an application gets screwy results if
they use a non-standard path.  More importantly, an application that
depends on paths does not allow one to install more than one version
of that application.

The Xen application xm fails respect this Unix tradition.  Multiple
installations of differing versions of xm will get very confused.

John

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 21 May 2006, at 03:58, John D. Ramsdell wrote:
> If you execute this command, you will note that the rule for
> assembling .S files is:
>
> COMPILE.S = $(CC) $(ASFLAGS) $(CPPFLAGS) $(TARGET_MACH) -c
>
> Note that you don''t give the assembler CFLAGS.  It''s not
a C
> compiler.
We fixed this for Xen itself some time ago. If there are other places 
in the tree that do this (maybe minios?), please do provide a patch.

  -- Keir


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Keir Fraser <Keir.Fraser@cl.cam.ac.uk> writes:
> On 21 May 2006, at 03:58, John D. Ramsdell wrote:
> 
> > If you execute this command, you will note that the rule for
> > assembling .S files is:
> >
> > COMPILE.S = $(CC) $(ASFLAGS) $(CPPFLAGS) $(TARGET_MACH) -c
> >
> > Note that you don''t give the assembler CFLAGS.  It''s
not a C
> > compiler.
> 
> We fixed this for Xen itself some time ago. If there are other places
> in the tree that do this (maybe minios?), please do provide a patch.
The Mini-OS makefile was recently patched so as to include the
following rules:

%.o: %.c $(HDRS) Makefile
        $(CC) $(CFLAGS) $(CPPFLAGS) -c $< -o $@

%.o: %.S $(HDRS) Makefile
        $(CC) $(ASFLAGS) $(CPPFLAGS) -c $< -o $@

Note the rules fail to include $(TARGET_MACH), which is part of the
default rule for COMPILE.S, and $(TARGET_ARCH), which is normally
part of COMPILE.c.  

When the appropriate GCC backends are installed on an i386 32-bit
machine, the $(TARGET_MACH) flags, and the $(TARGET_ARCH) flags can be
used to produce a Mini-OS elf file for both the 32 and 64 i386
architectures.  You don''t have to put your cross compilers in separate
locations. 

I decided to test the use of Mini-OS as a library.  My test
application included just one file, app.c, and it resided in a
directory outside the Xen sources.  I wrote the obvious Makefile, and
used the default rule to build app.o from app.c.

This Makefile fails, of course, because $(TARGET_ARCH) is set to
x86_32 by Config.mk, and the default rule is:

COMPILE.c = $(CC) $(CFLAGS) $(CPPFLAGS) $(TARGET_ARCH) -c

I hadn''t tracked down the source of my problem before I sent my post
last night.  I somehow thought that COMPILE.c used $(TARGET_MACH),
instead of $(TARGET_ARCH), and therefore thought a fix was plausible.
I now see that modifying Xen to work with the default rules is a big
pain.  On the plus side, tracking down this problem forced me to
look at Config.mk, and see I can select a cross-compiler by setting
CROSS_COMPILER to the bin directory of my cross compiler, rather than
setting my path.

John

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

The note I sent contained a misstatement.  TARGET_ARCH is being set in
the Mini-OS Makefile, not ../../Config.mk.  I meant to say that to get
all Xen Makefiles to use TARGET_ARCH and TARGET_MACH as they were
intended would be a pain.  Target information is currently being
placed into CFLAGS and LDFLAGS, and one would have to be careful to
separate the information correctly.  Not worth it.

John

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Keir Fraser <Keir.Fraser@cl.cam.ac.uk> writes:
> We fixed this for Xen itself some time ago. If there are other places
> in the tree that do this (maybe minios?), please do provide a patch.
To facilitate cut-and-paste of portions of the Mini-OS Makefile into
other Makefiles, this patch renames TARGET_ARCH to MINIOS_TARGET_ARCH.

John



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 22 May 2006, at 11:31, John D. Ramsdell wrote:
>> We fixed this for Xen itself some time ago. If there are other places
>> in the tree that do this (maybe minios?), please do provide a patch.
>
> To facilitate cut-and-paste of portions of the Mini-OS Makefile into
> other Makefiles, this patch renames TARGET_ARCH to MINIOS_TARGET_ARCH.
First, you renamed to MINIOS_TARGET_OS, not _ARCH, which makes no 
sense. Second, you added references to TARGET_ARCH and TARGET_MACH to 
rule patterns, which seems unnecessary and might have unwanted side 
effects.

  -- Keir


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Keir Fraser <Keir.Fraser@cl.cam.ac.uk> writes:
> First, you renamed to MINIOS_TARGET_OS, not _ARCH, which makes no
> sense. Second, you added references to TARGET_ARCH and TARGET_MACH to
> rule patterns, which seems unnecessary and might have unwanted side
> effects.
Please ignore this patch request.  No real need for change.

John

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel