Can Electric Make read makefiles from stdin?
We have some complex makefiles which rely on "echo blah | make -f -" to do some internal tasks. These are not easily rewritten as some come from open source packages. I was disappointed to discover when trying to switch to emake that it doesn't support makefiles on stdin:
% echo all: | emake -f -
make: -: No such file or directory
make: *** No rule to make target `-'. Stop.
Is this just an oversight? Any chance it's addressed in 7.0? We're using 6.0.1.40766.
Starting with Accelerator 11.0, Electric Make will automatically detect when it's been invoked to read a makefile from stdin and handle that in a manner compatible with gmake-based builds. However, be aware that in those cases emake will execute the submake in "local mode", meaning it will be a single threaded, monolithic job -- not handled using the submake stub as submakes usually are. For every case we've seen in practice, this is fine -- usually this construct is used for trivial activities. If you're trying to pipe some huge submake to emake, you'd be better off restructuring that to better take advantage of emake's capabilities.
Thanks, it's good to know at least that it's not just an oversight. Let me register two types of skepticism before letting this drop, though: First, "...relatively uncommon use case..." and "...you could explicitly invoke gmake, instead of using $(MAKE)..." both implicitly assume we have some control over the makefiles, but that's often not the case when a build includes third-party sources. We build proprietary code (drivers) against a lot of open source software such as the Linux kernel. If the Linux kernel build depends on this idiom, it's going to be very hard for us to use Electric Make to build our product for Linux building a Linux driver requires use of Linux kernel makefiles which we don't control. Second, does your point #2 maybe contain a bit of "awfulizing"? "Detecting the use of stdin" is just a strcmp() of the value passed to the -f flag versus "-"; that's not a lot of detecting. After that, yes, you'd have to read stdin to EOF and store the result in a temp file and then, presumably, "manage the storage and transmission of the file across the cluster". But isn't managing the storage and transmission of files across the cluster the heart of what emake does? I'd think this would just be a matter of throwing one more file into a pot already filled with similarly managed files. However, none of that matters in the short term. Thanks for clarifying that this is a known limitation.
@dboyce: #1: Can you show me where the Linux kernel build uses this idiom? As far as I know it does not.
.#2a: Obviously it's trivial to detect the use of "-f -". The question is whether we can tell if stdin is attached to a console, a file, a pipe, or some other source. It may not even be _possible_ to capture the content for later use.
.#2b: you're wrong to call these "similarly managed files." These files are not versioned, nor part of the the build output. Again, obviously I could invent a way to manage them, but it's just not warranted at this time.
\#1: Sorry, it turns out not to be in kernel makefiles per se but in some other Linux software. Like many companies, we ship products which are essentially a stripped-down Linux build plus our value added, so we don't build just the kernel but a bunch of related GPL code. Have a look at "netfilter" for instance which has some typically contorted automake code including "$(MAKE) -f - 2>/dev/null". \#2a: I still don't know why you need to care. The world is filled with programs that read from file descriptors without caring whether they represent a pipe or a socket or a disk file. When the user supplies "-f -" s/he is making a commitment that if you suck on that straw a valid Makefile will pop out. So you suck on the straw and if a valid Makefile doesn't come out you fail gracefully. Electric Make doesn't guarantee a good build even on bad input does it (though that would explain a lot about the pricing :-))? But anyway this is just for curiosity because ... \#2b: OK, I believe you that it's non trivial.
