From: Robert L. <rl...@gd...> - 2002-04-29 13:18:26
|
Hi. Below is a copy of a simple makefile which takes advantage of an implicit rule. file1.cpp is dependent on file2.h which lies in the "C:/anotherdir" directory. Makefile ------------------------------------------- OBJS = file1.o file2.o INCDIR = C:/anotherdir/ program: $(OBJS) g++ $(OBJS) -o program file1.o: file2.o: g++ -c file2.cpp -I$(INCDIR) --------------------------------------------- When I compile my program the first time everything works fine. If I make a change to file1.cpp save and retype make, the compiler knows that file1.cpp is out of date so it recompiles it, then relinks the program with the unchanged file2.o. GREAT! If I make a change to file2.cpp and retype make, file2.cpp does NOT get recompiled and the only thing that happens is a new version of program gets linked, with the old file2.o. :( What am I doing wrong ? Can I take advantage of an implicit rule, even if I have a header file in another directory. Does the VPATH variable, or vpath directive exist in the mingw32 make executable. I've tried this but it doesn't seem to work. Does anyone have a working makefile that creates programs that include headers from other directories, AND does not force you to clobber your object files every time you want to recompile? Thanks is advance. Bobby |
From: Alessandro A. <ant...@gm...> - 2011-02-24 20:42:45
|
Hi, all. I think the answer of my question is simple but I couldn't figure it out by my self. I have a project with the following structure: root/ +-> Makefile +-> source/ +-> bin/ *root* is the root directory of the project structure. Source files are in *source* directory and the object and binary files should be written in the *bin* directory. The *makefile* will be invoked in the *root* directory. My problem is exatly here. I don't know how to build a Makefile that looks for the source files in the *source* directory and write the binary files in the *bin* directory. I couldn't find some example in the Internet. Someone could point me to a reference link or something, please? Regards, Alessandro Antonello |
From: Keith M. <kei...@nt...> - 2011-02-24 21:55:08
|
On 24/02/11 20:36, Alessandro Antonello wrote: > I have a project with the following structure: > > root/ > +-> Makefile > +-> source/ > +-> bin/ > > ... I don't know how to build a Makefile that looks for the source > files in the *source* directory and write the binary files in the > *bin* directory. > > I couldn't find some example in the Internet. Someone could point me > to a reference link or something, please? You want to use the VPATH feature of GNU make -- google the online manual for the details. Basically, you construct your makefile as if all your files, source and generated objects are in the same directory. You make your root/bin the current working directory, and add the VPATH in ../Makefile to the *relative* reference to the sources: VPATH = ../source and invoke make as: make -f ../Makefile For further inspiration, you could look at any of my project sources, (e.g. mingw-get). They all use a VPATH build technique, with a hand crafted Makefile.in template for the Makefile; the autoconf generated configure script uses this to construct Makefile itself in the build directory (equivalent to your root/bin), with the VPATH definition automatically fixed up to point to the sources. (This offers the advantage of allowing relocation of the build directory relative to the source, so you can support, say, configuration for debug and release builds in parallel, each in their own directory, but sharing a common source). -- Regards, Keith. |
From: Greg C. <gch...@sb...> - 2011-02-24 22:01:55
|
On 2011-02-24 20:36Z, Alessandro Antonello wrote: [...] > root/ > +-> Makefile > +-> source/ > +-> bin/ > > *root* is the root directory of the project structure. Source files are in > *source* directory and the object and binary files should be written in the > *bin* directory. The *makefile* will be invoked in the *root* directory. > My problem is exatly here. I don't know how to build a Makefile that looks for > the source files in the *source* directory and write the binary files in the > *bin* directory. The easiest way IMO is to build in the bin/ directory, and use VPATH or vpath to find the source in the source/ directory. See this page: http://mad-scientist.net/make/rules.html#rule3 and the white papers on that site (the author is the gnu 'make' maintainer). |
From: José F. <j_r...@ya...> - 2002-04-29 14:48:33
|
On 2002.04.29 14:15 Robert Landle wrote: > Hi. > Below is a copy of a simple makefile which takes advantage of an > implicit rule. > file1.cpp is dependent on file2.h which lies in the "C:/anotherdir" > directory. > > Makefile > ------------------------------------------- > OBJS = file1.o file2.o > > INCDIR = C:/anotherdir/ > > program: $(OBJS) > g++ $(OBJS) -o program > > file1.o: > > file2.o: > g++ -c file2.cpp -I$(INCDIR) > --------------------------------------------- > > When I compile my program the first time everything works fine. > If I make a change to file1.cpp save and retype make, the compiler knows > that file1.cpp is out of date so it recompiles it, then relinks the > program with the unchanged file2.o. GREAT! This is because of the implicit rule. In fact the standalone "file1.o" has no effect whatsoever. > If I make a change to file2.cpp and retype make, file2.cpp does NOT get > recompiled and the only thing that happens is a new version of program > gets linked, with the old file2.o. :( Because you're overriding the implicit rule but no doing properly. It should be something like this instead: file2.o: file2.cpp g++ -c file2.cpp -I$(INCDIR) In other words, when you override a implicit rule, you have to do it all the way, adding the dependencies too. > > What am I doing wrong ? Can I take advantage of an implicit rule, even > if I have a header file in another directory. If you want to take advantage of an implicit rule you can not override, i.e., add your include without specificing a command, e.g., using CFLAGS: --------- OBJS = file1.o file2.o CFLAGS = -IC:/anotherdir/ program: $(OBJS) g++ $(OBJS) -o program ------------ The CFLAGS variable will be used by the implicit rule. > Does the VPATH variable, or vpath directive exist in the mingw32 make > executable. I've tried this but it doesn't seem to work. They exist. Most probably they didn't work due to the same problem as above. > > Does anyone have a working makefile that creates programs that include > headers from other directories, AND does not force you to clobber your > object files every time you want to recompile? > I think this question is address above too. > > Thanks is advance. > Bobby > If you want a piece of advice, 'Make' is a powerfull tool which can save a lot of time, but to make use of its full potential and avoid its caveats one has to have some expertise. To achieve that a thorough reading of its manual (which is is available in CHM format at http://mefriss1.swan.ac.uk/~jfonseca/gnu-win32/documentation/chm/index.html) must be made. José Fonseca |
From: Manu <con...@wa...> - 2002-04-29 14:58:26
|
"Robert Landle" <rl...@gd...> wrote: > Hi. > Below is a copy of a simple makefile which takes advantage of an > implicit rule. > file1.cpp is dependent on file2.h which lies in the "C:/anotherdir" > directory. You should use relative paths instead, like : ..\..\blah-dir\blah-dir > Makefile > ------------------------------------------- > OBJS = file1.o file2.o > > INCDIR = C:/anotherdir/ > > program: $(OBJS) > g++ $(OBJS) -o program > > file1.o: > > file2.o: > g++ -c file2.cpp -I$(INCDIR) > --------------------------------------------- The following is not complete, just some clues, you can inspire of it. [...] # mics variables, INCDIRS, OPTIMIZ etc... # see "Variables Used by Implicit Rules" in make's manual CXXFLAGS = -W -Wall -pedantic $(INCDIRS) $(OPTIMIZ) -fvtable-thunks -fno-rtti LDFLAGS = $(STRIP) $(LDBASEFLAGS) OBJS = file1.o file2.o TARGET = $(BINDIR)\my_app.exe # Targets all: $(TARGET) $(BINDIR)\my_app.exe: $(OBJS) $(CXX) -o $(BINDIR)\my_app.exe $(OBJS) $(INCDIRS) $(LIBDIRS) $(LDFLAGS) # ^^^^^^^ invokes g++ # dependencies file1.o: file1.cpp file1.h file2.o: file2.cpp file1.h etc.... I have a complete one here: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/visual-mingw/visual-mingw/src/makefile (click "view" to see it) > When I compile my program the first time everything works fine. > If I make a change to file1.cpp save and retype make, the compiler knows > that file1.cpp is out of date so it recompiles it, then relinks the > program with the unchanged file2.o. GREAT! > If I make a change to file2.cpp and retype make, file2.cpp does NOT get > recompiled and the only thing that happens is a new version of program > gets linked, with the old file2.o. :( > > What am I doing wrong ? Can I take advantage of an implicit rule, even > if I have a header file in another directory. > Does the VPATH variable, or vpath directive exist in the mingw32 make > executable. I've tried this but it doesn't seem to work. I think it should work with mingw. > Does anyone have a working makefile that creates programs that include > headers from other directories, AND does not force you to clobber your > object files every time you want to recompile? > > > Thanks is advance. > Bobby > > > _______________________________________________ > MinGW-users mailing list > Min...@li... > > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users |
From: Greg C. <chi...@mi...> - 2002-04-30 21:45:40
|
Robert Landle wrote: > [...] > Does anyone have a working makefile that creates programs that include > headers from other directories, AND does not force you to clobber your > object files every time you want to recompile? Read the 'white papers' by the GNU make maintainer here: http://www.paulandlesley.org/gmake/ Steep learning curve, but once you master it, your life will be much easier. If you'd like to see a complicated example, download http://groups.yahoo.com/group/actuarialsoftware/files/Illustrations/lmi-temp-20011225.tar.bz2 and look at GNUmakefile and the other files it uses. If you have questions about that, please write to me directly. |