Re: [gentoo-dev] [RFC] toolchain-funcs.eclass: functions to call compiler

[Mike Frysinger]

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