help-make
[Top][All Lists]
Advanced

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

Re: RFC: .ALIAS builtin pseudotarget


From: Fabio Alemagna
Subject: Re: RFC: .ALIAS builtin pseudotarget
Date: Thu, 23 Sep 2004 19:07:31 +0200

On Thu, 23 Sep 2004 11:46:48 -0500, Boris Kolpackov <address@hidden> wrote:
> > Well, obviously if I do use it, and it serves its purpose, it IS useful.
> 
> You forgot about one possibility: it may work but it's not the best
> way to do it. I was trying to reason you to the better way but you got
> defensive.

I've not gotten defensive, I've simply stated that it is useful,
unless you can show me another way, equally simple and effective, to
solve the problems I've needed to solve.

Simply saying "it's not useful" doesn't help anyone, does it?

> > Considering the patch is really tiny, I don't see the problem.
> 
> I am not deciding what goes in and what doesn't. However, I have
> doubts in its usefulness.

Which we're debating about. Let's not start a meta-discussion now, yes?

> > > Don't see how this can be useful...
> >
> > Well, what exactly you don't find useful?
> 
> This remark was about short_module_name that aliases all modules
> that are named like this.

The fact it aliases all modules is a side effect, welcome or not. If
you have the modules foo/baz and bar/baz, then obviously bulding "baz"
will build both of them. But most often you only have one baz
troughout your project, hence it functions as a shorthand to _that_
module.

> > > Let's try to stage a small project by the rules you gave above.
> >
> > No need to do that, the build system has been working for more than
> > one year already, there's a whole project composed of lots of modules
> > which uses it, you might look at it as reference (notice that the
> > Makefile needs to be reworked and refactored, but the concept and the
> > Makefile.tubs files are completely valid):
> > http://cvs.sunsite.dk/viewcvs.cgi/aweb/
> 
> Do you think I have nothing else to do? 

Well, I thought you were interested in this discussion?

> You don't send patch and then
> when asked where it is useful say "go study my build system".

I don't recall having done that. I've simply pointed out to a working
makefile, to save you the need to think one up yourself. Who's getting
defensive here? I really don't understand your reaction...

> That's bad manners.

Really? We must have different opinions about what really is "bad
manner". To me it seems I've gone to great lenght in explaining how
and why my patch is useful, and then pointed you out to a working
system which uses it, as reference. How's that bad manner, is beyond
me.

> > > 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.
> >
> > But the last rule is wrong anyway.
> 
> Well, I just followed your instructions. Here is the quote from your
> previous email:
> 
> 
> > 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)
> 
> 
> don't bother to reply,

Well, sorry, but I'm replying anyway. You might notice that there's no
action for that rule - you added an action. You will also notice that
I've stated DEPS lists module names - you've used them directly to
link in the executable, which is obviously wrong.

Not meaning to be harsh, but perhaps you could pay more attention,
rather than getting defensive?

Fabio Alemagna




reply via email to

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