On Sat, Feb 01, at 11:46 Αγαθοκλής wrote: > 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?
> 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. Actually by total coincidence, i created such a system in the last couple of days, so you may have a look¹ (a little bit different from the above description though). But in mho probably make is a way limited and probably overkill in cases. I mean it doesn't get too much of a code to do something like: Create a type for (read|open)dir(), with a couple of dir/file callbacks, that can check conditions and act accordingly. You can save/reuse this information, to (let's say) json format or even to a schema like flatbuffers or something like that anyway. What we are missing from make, imho, is something like a more complex conditional expression, to avoid ugly hacks which might be not even portable. I mean there is already the posibility today, at least in GNU make, to extend it, see 12.2 Loading Dynamic Objects, but as it says (in my quite recent copy at least) in 12.2.3 Loaded Object Interface, even the API is not considered stable, so... And as it has been said already, Makefiles are not portable, even the += assignment i think is not portable to BSD make. Anyway, still is a powerfull tool, though limited and hackish. But surely the answer to this, is not write such tools in Python! For god shakes! And since we are talking for ninja, there is a C (compatible with ninja) tool, which quite logically is called samurai, see at: https://github.com/michaelforney/samurai and which works great. Well if i had to do this kind of thing in a scripting language, well yes obviously that would be Lua (for a number of obvious reasons), and which by coincidence, Lua is the underlying reason for the above mentioned project. Anyway, have a good day and best regards there to the land of the rising sun. ¹ https://github.com/agathoklisx/ulenv.git (created mostly for demonstration reasons, i don't write in Lua, though during the research i came across nelua², that compiles to C and i'm thinking to do) ² https://nelua.io -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
