Re: [Gnu-arch-users] in-tree builds

[Stephen J. Turnbull]

>>>>> "Juliusz" == Juliusz Chroboczek <address@hidden> writes:

    TL> I'm saying: even if you want to get inventory to ignore
    TL> in-tree build-products, changing `untagged-source' is _not_
    TL> the right way to do it.  It's too error prone.

    Juliusz> Okay.  So what /is/ the right way to do it?

abentley (IIRC, or was it jblackwell?) already mentioned it:
explicitly list your build products as precious in =tagging-methods,
or perhaps better yet in .arch-inventory (or whetever the
per-directory methods file is).

    >>> Out of tree builds?  How do you do that...

    TL> Consider relying on GNU Make

    Juliusz> That's unfortunately not an option.

    TL> consider relying on the auto* tools,

    Juliusz> Tom... I'm trying to solve a problem, not to create new
    Juliusz> ones.

I see your point in both cases, but what that means is that you are
stuck with a very weak environment where none of the choices are
particularly attractive a priori.  Since you've invested more or less
heavily in making in-tree builds work, that's the way to go for you
... and arch will let you do it cheaply (ie, a one-line edit per new
build product at worst, and normally for free if the build product
matches .o or .pyc).

I'll tell you why _I_ don't like in-tree builds, though.  With several
important configuration variants that must be tested, I end up with
a {source-versions} X {config-variants} matrix that makes it hard to
figure out (in general) which files I want to be editing, because I
need to propagate the changes across to the other members of the the
same source-version class, but not necessarily to other source-version
classes.

How do you handle that?

-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.