%% "Martin d'Anjou" <[EMAIL PROTECTED]> writes: md> - Where are makefile located, in the same directory as source files?
Typically yes. md> - How do I avoid duplicating rules in every makefile? Put the common stuff in a common makefile and include it in the others. md> - Where are users expected to build targets? i.e. one level above the md> source files dir? inside them? Typically a user would type "make" in a directory after they have finished editing source in that directory. md> - Where should test cases reside? In which makefile do I put the md> rules for compiling a test and running it? This is beyond the scope of make. Do it however you like. md> - How do I link the dependencies such that making a test causes md> the entire project to be re-compiled (if and only-if necessary)? md> How do I get the rules to cross over directories when dependencies md> are located elsewhere? This is a very complex subject. Traditionally you would have a makefile in each directory that knows how to build the things in that directory. In a directory with sources it would build the sources. In a directory with subdirectories it would recursively invoke make in each subdirectory. In this case you could have your tests jump to the top of the source tree and invoke make there, which will build everything. This is not usually how it's done, though, because it's very slow. Usually it would be done in two separate phases with perhaps a "do it all" target that does both of them, so users could choose to either run "just the build" or "just the tests" or both. md> - How do I make the targets (objects and executables) re-locatable md> (i.e. building on local drives instead of network drives) without md> re-writing the rules? Put the target directory in a variable and use that instead of hardcoded paths. Use variables and relative paths to find headers. etc. Then you can change that variable (maybe by overriding it on the make command line: make OBJDIR=/some/other/dir). md> Do you know of a book that talks about some advanvced makefile md> methodology? Well, there's an O'Reilly book on managing projects that talks about make, but it's very UNIX-centric. md> I am not using C, nor Java, so it would be good if the book was md> not too language centric. Languages are really superfluous to make. It doesn't have any very special support for any language. So, books that talk about building C code will give you just as much info as anything else. Building Java with make is a very difficult, very unrewarding experience, though, because of the structure of the Java language and build tools. -- ------------------------------------------------------------------------------- Paul D. Smith <[EMAIL PROTECTED]> Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org "Please remain calm...I may be mad, but I am a professional." --Mad Scientist _______________________________________________ Help-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/help-make
