From: Keith M. <kei...@to...> - 2006-03-16 10:40:32
|
dw dw wrote: > Sorry for emailing you all directly but for some reason my > emails to the MSYS mailing list are failing. I'll try to post > again tomorrow but for now here is what i want to say. Please *don't* mail list members privately. If you want private tuition, then perhaps we can negotiate an appropriate fee; otherwise please keep your queries on the mailing list. > Thanks for your replies everybody. I'm still having a few issues > so hopefully you'll be able to help me resolve them. > > I have 2 Windows environment variables set via the Windows control > panel. These are: > > API = /c/work/game/api > API_SOURCE = $API/source I explained this yesterday (sigh)! In Windows Control Panel, referring to variables using UNIX syntax is *wrong*; you should set API_SOURCE to %API%/source, and *not* $API/source. In any case, unless you need these variables outside of your MSYS environment, you should *not* use Windows Control Panel to set them; define them directly from the command line as you need them, or in $HOME/.profile, if you want them permanently. (Don't forget to export them, if you need `make' to see them). And furthermore, if you design your Makefile correctly, you probably don't *need* these particular environment variables at all. ------------------------------------------------------ > I have a .mk file which containts: > > ifndef API_SOURCE > SOURCE_DIR=$(API)/source > else > SOURCE_DIR = $(API_SOURCE) > endif What is $(API) here? If you rely on a definition being present in the environment, then your Makefile is fragile. Better to also provide an explicit default definition for API here as well, and allow the user to override it, either by an environment variable setting, or better still, by an explicit API=/some/path assignment argument to `make' itself. ------------------------------------------------------ > I have a Makefile which contains: > > include $(GAME_DIR)/game_defs.mk > > all: > $(MAKE) -f Makefile -C $(SOURCE_DIR) Why force the build in the source directory? Usually, the exact opposite is preferable. I hinted at this yesterday, but let's formulate a more concrete example; let's say we are going to build project `demo', and we have set up the following directory hierarchy: $HOME/projects + sources | + demo | : + demo.c | : : + build : + demo : : + Makefile Now, we have all our sources in `$HOME/projects/sources/demo', and we will build the project in `$HOME/projects/build/demo', so we $ cd $HOME/projects/build/demo Let's now consider what we should have in our Makefile, (that is the file `$HOME/projects/build/demo/Makefile'): --------8<------------------------------ srcdir = ../../sources/demo VPATH = $(srcdir) CC = gcc OBJEXT = o EXEEXT = .exe all: demo$(EXEEXT) demo$(EXEEXT): demo.$(OBJEXT) $(CC) -o $@ $(CFLAGS) $(LDFLAGS) demo.$(OBJEXT) $(LIBS) demo.$(OBJEXT): demo.c $(CC) -c -o $@ $(CFLAGS) $(srcdir)/demo.c --------8<------------------------------ (Actually, the two rules for `demo$(EXEEXT)' and `demo.$(OBJEXT)' are more explicit that they need to be; for this simple project, make's implicit rules would probably suffice, but I thought it best to show these for illustration). Note that I've specified an *explict* definition of `srcdir', as a *relative* path from the build directory, (which will be current when you invoke `make'), and that `VPATH' tells make where it must look for prerequisites in it's dependencies, when these aren't satisfied in the build directory. ------------------------------------------------------ > So when i load up MSYS and type Make i'd expect the make command > to resolve to something like this: > > make -f Makefile -C /c/work/game/api/source > > but as you know it actually displays this: > > make -f Makefile -C $API/source > *** No such file or directory Simply because you've specified invalid syntax, in the definition of API_SOURCE. (See above). > Could someone please show me how i would use the "eval" command > to get this working. If you are even considering using `eval' in this context, then your entire build system design is probably flawed. Regards, Keith. |