On Wednesday, June 02, 2010 09:17:00 Michał Górny wrote: > On Wed, 2 Jun 2010 03:16:12 -0400 Mike Frysinger wrote: > > On Monday, May 31, 2010 15:12:46 Michał Górny wrote: > > > There are many simple applications which come without neither a > > > sophisticated build system or even a tiny Makefile. In some cases, > > > such applications aren't even packages as tarball -- a single, > > > compressed source file is published instead. > > > > > > In case of these applications, ebuilds inherit > > > toolchain-funcs.eclass to retrieve compiler information > > > (tc-getCC/tc-getCXX) and call compiler manually, passing > > > appropriate flags. > > > > use emake then and leverage make's implicit rules. > > The implicit make rules are less universal and -- in the fact -- pretty > poor. They're strictly make-dependant, which reduces the amount of > control over their behavior. In my opinion, if we should ever use such > behavior, it should be rather technical implementation of the functions > I'm proposing instead of inline use.
ebuilds requires GNU make which means the implicit rules are "universal". not that i really know what you're talking about. the rules are also clearly documented and support all the proper flags we currently support. > POSIX (man 1p make) defines only simple rule for C files: > $(CC) $(CFLAGS) $(LDFLAGS) -o $@ $< POSIX rules are irrelevant. read the GNU make documentation. > Namely, advantages of my solution over directly calling emake is: > 1) direct control over how compiler will be called == better > portability, irrelevant. this is like saying we should use POSIX shell code instead of bash because it's "better portability". we use the tools that are required by the ebuild system and that means GNU make. > 2) possibility of using any output filename (with emake we'd have to > rename), the -o location is irrelevant in the compile line, and most packages name the source file the same as the output, so not that big of a deal > 3) possibility of clearly using multiple input files, yep > 4) possibility of using any input file suffix, perhaps, but very few packages are stupid enough to name a file moocow.txt when it's really a C file > 5) clear separation between user-specified and ebuild-specified flags > (yes, I'm aware of '+=' GNU make extension). hard to sat it's irrelevant > And after all, starting a make jobserver for a single compiler process > doesn't seem really useful. and serializing multiple files is worse > > sys-apps/unscd is a pretty straight forward example. > > In my opinion it's rather a poor example. It's the simplest case > possible -- single file, no additional flags, no libs. and there are many like it btw, toolchain-funcs is not really the best place to add this. it's an eclass for querying, not compiling. better to start a new one. -mike
signature.asc
Description: This is a digitally signed message part.
