[haiku-development] Re: question on planned build system feature -- 'generated' folder naming scheme
- From: Matt Madia <mattmadia@xxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Fri, 30 Jan 2009 18:34:19 -0500
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, which can
be displayed with configure --help
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
earlier someone and I discussed a few possible implementations.
`configure --haiku-output-dir /custom/generated` prepare the folder
and one of the following possibilities:
1) echo to the user that they need to cd /custom/generated ; jam [args]
2) having configure generate an individual launch script, which
resides in haiku's top level source directory. the script would
export HAIKU_OUTPUT_DIR , accept parameters and relay them to jam.
the script filename would be indicative to what is being built. eg
"x86gcc2 -j2 -aq" would initiate jam -j2 -aq for the x86gcc2
generated folder.
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 all that, I'd be happy to have --haiku-output-dir and #1 implemented.
I personally like #2, but I understand that people may not like to
having additional scripts generated by configure.
--mmadia
Other related posts:
