[Top][All Lists]

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

Re: [Gnu-arch-users] configs?

From: Dustin Sallings
Subject: Re: [Gnu-arch-users] configs?
Date: Fri, 26 Sep 2003 10:29:42 -0700

On Friday, Sep 26, 2003, at 07:47 US/Pacific, Robert Anderson wrote:

Consider a fairly generic set of Makefiles useful for building more
one project.  You'd want configs for each project that that set of
Makefiles can build.  As one example.

        I'm not sure I follow this example.  Are you suggesting having a
project that is made up of Makefiles and references other projects that those makefiles can build? Either I'm not understanding that (which is
likely since I haven't slept nearly enough this week) or it seems a
little contrived.

It's not at all "contrived," whatever that is supposed to mean.  It's
how package-framework work.  It's how I work.

``not spontaneous or natural'' It sounds like a potential solution to a problem that only exists when you try to think of a problem that can be solved that way. I don't mean to say you're not working in a good, efficient way. It just sounds like something I either don't understand, or wouldn't want to do.

that pulls in a couple other C-based projects, for example.  I don't
see why I'd need to have more than one set of configs in a single
branch pulling in different sets of sub-projects.

Because you build more than one variant of your code? One that pulls in
a gui "library" for the gui version, and one that pulls in a cli
"library" for the cli version.  There's infinite possibilities.

I've always handled these types of details in my build system, not in my revision control system.

  Shouldn't a single
sub-project set definition be adequate for any given branch of a

Well you _could_ branch your wrapper project once for every config you'd
like to use, if that's what _you_ want.  But forcing a user to do that
is a limitation and not a feature.  Maybe I don't want to "get" from
different branches to build different configs.  In fact, I don't.

That's fine, I'm not suggesting taking away the feature, I'm suggesting that it might not need to be required for anyone who wants to build a multi-tree project.

I don't have a need to have more than one configuration in a given project, but I'm required to set my project up in such a way that I could have many of them, and then remember what I called the thing (which I don't, so I end up looking anyway). Why not just have a single config with the ability to swap it out at get time. For example, one of these three scenarios:

I check out a project. The default config is automatically applied, but I can swap it out after checkout and apply a different one. I think will deal with the most common use-case.


I check out a project. The default config exists, but is not applied until I do a build-config. build-config takes no arguments, and only applies the default config. Another command will load the a config so that it becomes the default.


I check out a project. The default config exists, but is not applied until I do a build-config. If I specify no arguments, the default config will be applied, otherwise an alternate config will be applied.

Dustin Sallings

reply via email to

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