Re: [openMSX-devel] Building (replacing auto* ?)

[Joost Y. D. <jo...@lu...>]

'Maarten ter Huurne' wrote about 'Re: [openMSX-devel] Building (replacing auto* ?)' - Sun, Feb 16, 2003 at 10:51:27PM CET
> On Sunday 16 February 2003 20:52, Joost Yervante Damad wrote:
> 
> > in attachment a sample of a makefile based on the type of makefile
> > Marcel Harkema made for 10 Towers (a MUD).
> >
> > What do you think of it?
> 
> It's a good start.
> 
> I noticed he uses vpath. For a small project that's OK, for a large project it 
> may be a problem. Basically what happens with vpath is that a search path for 
> sources and headers is created. So the good thing is that you don't have to 
> administrate in what directory files reside. The bad thing is you can never 
> have two sources with the same name, even if they are in different 
> directories.

Thanks for the explanation, this was not fully clear to me.

> I'm not sure whether openMSX is a small or a large project, I think it's 
> inbetween. But it will probably only get larger: more devices, more ports, a 
> GUI, a debugger, network play etc. So I'm inclined to choose the robust 
> solution (full directories) over convenience (vpath) here.

I consider it a large project.

> Another difference with the Makefiles I wrote at work, is that wildcards are 
> used to spot all sources. The advantage is that you don't have to list the 
> source files, the disadvantage is that you cannot exclude files from the 
> build without either renaming them or moving them out of the source 
> directory. Note that in Marcel's Makefile, there is still a list of 
> directories ("." and "foo") that has to be administrated. With some clever 
> shell scripting this can be avoided, but at the cost of portability.
> 
> At work we had two subdirectories of which only one would be built, depending 
> on the hardware capabilities of the target platform. In openMSX we might want 
> to exclude certain source files as well, for example a Windows build will 
> probably not use the XRenderer. It is possible to just include every source 
> and then use #ifdef directives to exclude classes (SDLGL uses this right 
> now), but I think excluding them from the build altogether is cleaner.

I agree. We can easially add ifdef's to the makefiles to disabled enable
certain parts. A separate included makefile could contain all the
settings that steer this.

> I think the two decisions are related: vpath + wildcards requires the fewest 
> Make rules, while full directories + listing sources is more scalable and 
> supports diversity. The combination of vpath + listing sources would be 
> messy: one huge flat source list. The last combination, full directories + 
> wildcards, may be useful though. If we do that, we can still have diversity 
> in the build process, although only at directory level, not at file level 
> (you either include or exclude a whole directory, no control over individual 
> files).

Another methodology which is very handy is including makefiles.
This allows for example to have parts of the makefiles be generated and
they are included from the main makefile.

This can also be used to make a makefile per directory, and include them
all in the main makefile. Each directory specific makefile just adds
its files to the lists.

> By the way, something that is missing from Marcel's Makefile is ".phony". If 
> you write for example ".phony: all clean", you declare that "all" and "clean" 
> are not files, but logical target names. So if for some reason there will 
> ever be a file called "all" or "clean" in the file system, your build will 
> not break. Also, it helps the reader to understand what is going on.

It was not missing in Marcel's file. I removed it, my bad.

> > It supports dependency-tracking and automatic finding of sources.
> > Objects end up in o/, dependency files in d/.
> 
> I prefer to have all generated files under a single directory. Also, we might 
> as well use a few letters more and call the directories "obj" and "dep", in 
> good old Unix 3-letter fashion.
> 
> To summarize things with some examples:
> 
> I am in favor of a structure like this:
> openMSX/Makefile
> openMSX/src/cpu/CPU.cc
> openMSX/src/sound/Mixer.cc
> openMSX/generated/dep/cpu/CPU.d
> openMSX/generated/dep/sound/Mixer.d
> openMSX/generated/obj/cpu/CPU.o
> openMSX/generated/obj/sound/Mixer.o
> openMSX/generated/bin/openmsx
> openMSX/generated/doc/<Doxygen output files>
> 
> With vpaths the structure would look like this:
> (the dep and obj directories would be flattened)
> openMSX/Makefile
> openMSX/src/cpu/CPU.cc
> openMSX/src/sound/Mixer.cc
> openMSX/generated/dep/CPU.d
> openMSX/generated/dep/Mixer.d
> openMSX/generated/obj/CPU.o
> openMSX/generated/obj/Mixer.o
> openMSX/generated/bin/openmsx
> openMSX/generated/doc/<Doxygen output files>

Looks good. I'll play some more with these ideas with my little
MIDI-event decoder program ;)

Joost