[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
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
[Gnu-arch-users] Re: configs?, Samuel Tardieu, 2003/09/26
Re: [Gnu-arch-users] configs?, Andrew Suffield, 2003/09/26