Re: [Gnu-arch-users] configs?

[Dustin Sallings]

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

> > > Consider a fairly generic set of Makefiles useful for building more
> > > than
> > > 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
> > project?
>
> 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.

        -or-

	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.

        -or-

	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