On Sat, Feb 01, at 02:09 Akira Urushibata via lfs-dev wrote: > The greatest surprise I got from my recent survey is that many > programmers do not have experience with "make." Come to think of > it, this may well be the case considering the great popularity of > scripting languages.
> This made me think: which package of the 70 or so which comprise > LFS has a makefile which would serve as good reference for someone > starting to study "make" and makefiles? For a study in depth, there is of cource the GNU make manual which covers every concept in details and does it (usually) with enough clarification. In my opinion though, only a subset of it is usually what is has being used in practice, so probably the following sources provide all the needed information: http://nuclear.mutantstargoat.com/articles/make/ https://gist.github.com/isaacs/62a2d1825d04437c6f08 though the latter, but which i like most, it doesn't speaks about conditional expressions, but this is not really hard to get, here is an example: DEBUG := 0 DEBUG_FLAGS := -Wextra -Wshadow -Wall -Wunused-function -Wunused-macros ifneq ($(DEBUG), 0) # or ifeq ($(DEBUG), 1) FLAGS += $(DEBUG_FLAGS) endif So if you issue: make DEBUG=1 this will pickup the debuging flags. Conditional expressions, can take an else clause also. So yes this info, is probably that is what most developers or LFS'ers needs to know in my opinion. Keep in mind, that Makefiles can be quite complicated, such those that usually constructed by generators. But usually those generators make some tests for the environment such: machine architecture, compiler and the version of the compiler, the operating system..., so in that case they don't really care for readability, so do not have such expectactions from them (if you ever had). But for hand written Makefiles, is always wise to not complicate things, as it is also that developers should know that Makefiles are not really portable across different operating systems and make implementations (BSD's have dmake for instance), that is why is wise to keep them simple and use the portable portion, which should be enough for most of the cases for a small/medium size project. And a small last thing, This is from the survey: 3. Are you familiar with "make"? (1) Know little or nothing about it :5 (2) Use for project build, using makefile provided by the project leader :3 (3) Have written my own makefiles :4 (4) Can handle advanced features (nested makefiles, conditionals, etc.) :0 and speaking for (4) and nested makefiles, so google for "why a recursive make is considering harmfull". Though i do not remember the details, there were some good points there (a couple at least). In my case and for a past project, and because of some (unneeded :-)) complexity, i created such a system (based on Makefiles), and it took me time to implement, but then it worked flawselly and could handle different requests quite uniformilly. But then again, sometimes i should touch, especially at the early state of development, at least a couple of Makefiles to modify or extend the system. No big changes though! Usually a variable name change or the addition of a variable. But if you've missed a Makefile adaption then (let's say) because that code (that was handled by this Makefile), it shouldn't compiled anymore (probably because it was merged in another unit, or it should be compiled with other variable's values, the result wasn't reliable, because simply you thought you've fixed something but the end result didn't get the development. But the compiler did what you told it to do, but it wasn't that you wanted to. (it was really a couple of carefull seconds to edit that Makefile), but you know, we are humans :-)) The long story short, is that this wasn't perfect, unless of course the compiler (and that is the good case), thankfully discovered this incostistency. But it was fragile. Though it could go to the next step, providing to the mechanism some more details, so such mistakes could be caught, and teach a bit the system with some heuristics, to make it a little less dummy :-). But then at this time you do it, you through away any abstraction (already fragile at this stage), because such systems, need to go to some more inner details to make them work for your happiness. But then the next thing that came, it was when i've tried to use this system, to another project. It was painfull, as it should be adopted to another system with other requirenments (i mean possible but it wasn't without to spend again some time. We said that the abstraction had already gone! So such systems, are usually is wise to be used in long/lived big sized projects, and then it can really be the best choise (almost undoubtly), because are independable, flexible at they are really tailored to the specific needs, and actually much simpler to use at the end (for this there is certainity). You just keep a hidden directory in the root's project dir, with a couple of basic functions and variables (tailored for your environment), and then to any depth of the project hierarchy, a Makefile, with the absolute necessary variables, which inherit from the top Makefile or the previous Makefile (kinda like namespace things), and walks a step deeper in the hiearachy. At the last Makefile, which probably does the compiling, there could be a couple of tweaks, usually none though. So if you spend this time to design such a thing and you know that people will work in this thing for eternity, it might be cleaver to waste your valuable time to have some fun first, because it is fun, and at the same time it could produce some lazyness in your future time. I mean, that would be my approach. But definitelly Makefiles, besides their warts, that exist yes true, but at the same time can be powerfull, and then yes probably worths to study. But best is to study the mechanics and not so the syntax. Regards, ag -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
