[haiku-development] Re: question on planned build system feature -- 'generated' folder naming scheme
- From: Ingo Weinhold <ingo_weinhold@xxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Sat, 31 Jan 2009 19:30:18 +0100
On 2009-01-31 at 00:34:19 [+0100], Matt Madia <mattmadia@xxxxxxxxx> wrote:
> On Fri, Jan 30, 2009 at 4:39 PM, Ingo Weinhold <ingo_weinhold@xxxxxx> wrote:
> > That's nice, though I don't quite understand what problem you intend to
> > solve. You can have as many output directories as you want -- each with a
> > different target architecture, gcc version, and other build settings --
> > and
> > you can run jam in any output directory to build something there (even
> > concurrently, if you want). So there's in general no need to switch target
> > architecture and gcc version.
> >
> > The only inconvenience I see is if you prefer to jam in the source tree,
> > but
> > don't use (only) the default "generated" output directory. In this case
> > setting the HAIKU_OUTPUT_DIR environment variable allows you to "switch"
> > between output directories. If you want to do that more permanently, you
> > can
> > set it in your .profile/.bashrc/whatever or use François' method and
> > symlink
> > to "generated".
>
> For what it's worth, this was all spurred while working on getting
> Bitten, http://bitten.edgewall.org/ to work across all platforms for
> all scenarios with as little pain as possible.
> (That is also the reason for my recent ticket+patch regarding --use-32bit )
>
> Initially, I was never aware that the build system was already capable
> of placing all objects and configuration data outside haiku's top
> level source dir.
>
> Upon learning how it's currently done, I didn't like that the user was
> required to manually create the directory, change to it, and call
> ../relativePath/configure [args]
> IMHO, that's something better suited for a configure option,
I disagree. The way it works now is kind of quasi-standard due to the popular
auto tools. Since one usually wants to build right after configuring and thus
wants to cd into the output directory anyway, there isn't really any
additional overhead -- it's a "mkdir ..." instead of adding
"--haiku-output-dir ..." to the configure command line.
I'm all for making the build system as easy to use as possible, but I really
don't want to add an option that just adds another way of accessing a feature
without simplifying it.
> which can
> be displayed with configure --help
I don't see why we can't add one or two sentences to the usage text
explaining how non-default output directories work.
> After that, I was hoping that configure and jam could:
> -- be run in haiku's top level source dir
> -- reduce the user's actions when working with multiple builds , as
> opposed to just a single external generated dir
I suppose that's mostly a question of your workflow. I have a terminal tab
for each configuration I'm interested in, each shell's working directory set
to the respective output directory. So building for some other configuration
is just a matter of switching to the tab and running jam.
I understand that other people have different workflows. Like just using a
single shell for navigating the source tree, greping for stuff, and invoking
jam. The build system generally supports doing that, but switching between
build configurations requires either specifying HAIKU_OUTPUT_DIR explicitly
or symlinking "generated". I'm fine with working on a more comfortable
solution for this use case, but generating jam wrapper scripts in the top
level directory doesn't help much, if you're not in that directory, nor is
putting generated files in the top level directory a particularly elegant
solution.
[...]
> 3) to somehow creating some type of jamrule or definition that would allow:
> configure --haiku-output-dir /blah ; jam x86gcc2 -j2 -aq @disk
> the jamrule/definition/thingie would manage HAIKU_OUTPUT_DIR and any
> other magic
After François mentioned that selecting the output directory by build profile
would be nice, I thought a bit about it, and it could be solved by
introducing an optional EarlyUserBuildConfig, which would be included very,
well, early. Early enough at least that it could changed HAIKU_OUTPUT_DIR.
Depending on what one personally prefers one could do that by build profile
or by some additional parameter (e.g. "x86gcc2").
CU, Ingo
Other related posts:
