help-make
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: RFC: .ALIAS builtin pseudotarget


From: Boris Kolpackov
Subject: Re: RFC: .ALIAS builtin pseudotarget
Date: Thu, 23 Sep 2004 11:00:33 -0500
User-agent: Mutt/1.5.6i

Fabio Alemagna <address@hidden> writes:


> > > > .ALIAS: alias
> > > >
> > > > alias: foo.c
> > > >
> > > > foo.o: alias
> > > >         $(CC) -o $@ -c ???
> > >
> > > I get what you mean, so the limited use of this special target perhaps
> > > doesn't warrant it the right to be added to Make.
>
> On a second thought, though, I'm not sure it's usage is really
> limited. In the above example, you're obviously using the wrong
> approach. .ALIAS is not meant to be used as a variable, .ALIAS is
> meant to be used as a .PHONY target which however can be used as
> prerequisite of another target.

As I said before, IMO, .ALIAS is useless because (1) when you need
timestamp you also need real target name and (2) when you don't need
real target name you don't need timestamp. The second case is covered
by .PHONY and the first - by normal targets. Therefore I don't quite
see where .ALIAS is useful. But let's go to your example.


>
> As said, I found the need for this in my build system.
>
> In my build system you have modules, modules are of certain types
> (executable, library, and so on), and each module type induces certain
> properties on the module itself, properties which can be set and
> gotten by using a well defined naming convention for variables.
>
> Modules can depend on other modules, meaning that before one module is
> built, another must be built.
>
> A module's name is defined as the pathname of the file the module is
> going to build, relative to the distribution directory.
>
> The distribution directory is the directory where all modules are
> going to be placed.
>
> Modules can be built in 3 ways:
>
> 1) typing "make" in the toplevel source directory (this is going to
> change, allowing one to run make from any directory in the tree),
> which makes all modules in the source tree.
>
> 2) typing "make full_module_name", where full_module_name can be
> something like path/to/module
>
> 3) typing "make short_module_name", where short_module_name is a
> shorthand for the module name. There are 2 kind of  shorthands:
>
>     3.1) $(dir full_module_name), which builds all modules that are
> going to be put in the
>            same directory
>
>     3.2) $(notdir full_module_name), which builds all modules with the
> same filename, even
>            if they're going to be built in different directories.

Don't see how this can be useful...

>
> Defining dependencies for a module is done this way:
>
>     full_module_name/DEPS := module_name1 ... module_nameN
>
> where module_nameX can be either a full_module_name or a short_module_name
>
> The build system handles this by simply defining full_module_name and
> both variants of short_module_name as .ALIAS'es to
> $(distdir)/full_module_name, and then simply adds a rule like this:
>
>     $(distdir)/full_module_name : $(full_module_name/DEPS)

Let's try to stage a small project by the rules you gave above. Say we have
module `foo/foo' (executable) and `foo1/libfoo.so', `foo2/libfoo.so' and
`bar/libbar.so'. So here we go:

---------------------------------------------------------------

# rules for foo1/libfoo.so
#
$(distdir)/foo1/libfoo.so:
        build-foo1-foo.so

.ALIAS: foo1/libfoo.so
foo1/libfoo.so: $(distdir)/foo1/libfoo.so


# rules for foo2/libfoo.so
#
$(distdir)/foo2/libfoo.so:
        build-foo2-foo.so

.ALIAS: foo2/libfoo.so
foo2/libfoo.so: $(distdir)/foo2/libfoo.so


# rules for bar/libbar.so
#
$(distdir)/bar/libbar.so:
        build-bar-bar.so

.ALIAS: bar/libbar.so
bar/libbar.so: $(distdir)/bar/libbar.so


# libfoo.so
#
.ALIAS: libfoo.so
libfoo.so: $(distdir)/foo1/libfoo.so $(distdir)/foo2/libfoo.so


# rules for foo/foo
#
foo/foo/DEPS := libfoo.so       \ # short module name of type 2
                bar/libbar.so     # full module name


$(distdir)/foo/foo: $(foo/foo/DEPS) # ???
        g++ -o $@ $^

---------------------------------------------------------------

The last rules won't work because when we link we need real libraries,
their aliases are not good enough anymore.

I will reply to the second part of your post separately.

-boris

Attachment: signature.asc
Description: Digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]