OT: Wine build system tech info

[David Elliott]

On 2002.02.13 04:47 Vassilis Virvilis wrote:
> Halo wine-devel people,
> 
> Although I understand you probably "enjoy" one of the
> best or worst  f^H
> debates of all times (who said wine devel is immune to
> flamewars after all?
> :-) I would like to pose a somewhat off topic question
> but still quite
> technical.
> 
Actually, this is probably more ontopic than any of the license flames 
have been.  Need to remember to put on the asbestos underwear before 
reading this list anymore.

> As part of a private investigation I noticed that both
> WINE and LINUX kernel
> build systems have a mkdep utility which generates in
> clude file
> dependencies. What I am looking for is to understand
> the reasons behind this
> decision for the two very popular projects instead the
> recipe
> suggested by GNU make documentation.
> 
THANK YOU!

Off the subject of Wine, but relative to this particular discussion, I 
have been working on a project at work and I briefly investigated Wine's 
makedep system, and then noted that X11 has its own makedepend command 
(which is actually installed onto the system).  What I have done right now 
is to use the X11 one to handle my dependencies.  I really don't like this 
as it chokes on some of the #if defined(SOMETHING) || 
!defined(SOMETHING_ELSE) type constructs in wxWindows code.  It also seems 
to like to do deps for all the system headers as well (well, you can 
specify ONE system directory it won't do deps against, but that's lame).

Trying to rip Wine's makedepend out was even worse.  I tried it first 
since when I thought make depend the first thing that came to mind was all 
the times I've typed that compiling wine every few days at least.  At 
least the X11 makedepend had a good manpage.

> Here is what GNU MAKE suggests as the preferred way to
> handle dependencies.
> 
> #---------Makefile Start
> TARGET=a
> SOURCES=a.c b.c
> CFLAGS=-ansi -pedantic -Wall
> 
> OBJECTS=$(SOURCES:.c=.o)
> DEPS=$(SOURCES:.c=.d)
> 
> %.d:    %.c
>         set -e; $(CC) -MM $(CPPFLAGS) $< \
>                 | sed 's/\($*\)\.o[ :]*/\1.o $@ : /g'
> > $@; \
>                 [ -s $@ ] || rm -f $@;
> 
> $(TARGET): $(OBJECTS)
> 
> include $(DEPS)
> #---------Makefile End
> 
> This method has the several disadvantages:
> 
Before we get to the disadvantages I'd really like to point out that the 
.d targets would seem like a more reasonable way of working with make.  
Considering that you can be sure you won't need to update the dependency 
info (the .d file) unless the source has changed this will actually save 
you time when rebuilding the project over and over again.

> i) It is GNU specific (unportable):
>         a) Needs accumulative dependencies. That means
>         a.o:    a.c
>         a.o:    a.h
>         does not override the first entry but it means
>         a.o:    a.c a.h
> 
Assuming you depend on the standard target to make a .o from a .c (or have 
defined your own) then there should be no need to have the a.o: a.c line 
in the makefile itself and thus the "a.o: a.c a.h" style line can be put 
in the dependency info (like wine's make depend)

>         b) It requires the include statement
> 
>         c) It requires that MAKE will reload the
> Makefile as soon as it
>         realizes that the Makefile or any of included
> file has been changed.
> 
These to can be gotten around by going back to an actual make depend 
target that must be run before doing a make.  For a non-GNU make you would 
just make all of the .d files and then append all of their contents to the 
makefile as per a usual make depend.

>         d) It uses compiler specific features.
> 
Man, that's a shame that more compilers don't support that.  Actually, it 
seems to just invoke the preprocessor to do this, so one could 
theoretically just use the GNU cpp to generate the dependency info without 
using the rest of gcc.

> ii) Speed.
>         a) Files has to be parsed twice during
> compilation.
> 
Of course.  With any dependency system you are going to have to parse all 
of the source files to generate the dependencies and then actually compile 
them.  What is the problem?  By compilation I assume you mean the build of 
the whole project, not the compilation of one individual source file.

>         b) Slight changes to config.h may result in
> unnecessary,
>         uncontrolled compilations.
> 
Umm yeah, ./configure; make depend; make; touch config.h; make and watch 
it all recompile.

> 
> ---------------
> 
> I would like to know if there are any other reasons
> that is not listed here
> and or if any of the reasons listed above is more
> significant than
> the others.
> 

I think it's more of an issue that a dependency system is pretty trivial 
to implement with the exception that doing it means time was spent that 
could otherwise have been spent programming.

I don't think the fact that GNU has a standard for makefile dependencies 
is going to convince Alexandre to change the tree.  Nor do I think Linus 
will be convinced to change the Linux tree.  However for my own projects 
I'll keep this in mind when I decide to do a bit of house-keeping.

I am by no means a make-guru... however I do believe that Alexandre is.

-Dave