[Dev] Streamlining development outside of chandler dir, including
debugging native code
Andi Vajda
vajda at osafoundation.org
Wed Jul 28 04:51:14 PDT 2004
Another approach to sparing the extra install step would be to tell Chandler
where the binaries are. You and Markie just went through the exercise of
moving release|debug one level down, into the chandler directory. If this
location for release|debug were not hardcoded but configurable, say with a
command line flag, or an environment variable, then you could tell Chandler
that release|debug were inside external, for example, or wherever else you
choose. This has the added benefit that, when tracking down build problems,
you can keep multiple binary trees ready and run the same Chandler against
each of them to see what changes and how.
Andi..
On Tue, 27 Jul 2004, Heikki Toivonen wrote:
> The apps team at least is finding the need for an easy solution to be able to
> debug native code. My suggestion for this is to do a full build when you need
> that. (make install build may work in some case if you have the exact same
> compiler etc. as the official build machine?)
>
> There have been reports that doing a full build is still hard. Aparna has
> documented her experience, and we will update the instructions based on that.
> Also, we will be setting up new tinderbox machines that report the status of
> full builds.
>
> When you actually need to change some native code, it is currently quite
> tedious in my opinion, and I filed a new bug to fix that:
>
> http://bugzilla.osafoundation.org/show_bug.cgi?id=1642
>
> However, we have differing views of this - some think this is not a good idea
> and would only want it if it did not affect the current way of doing full
> builds. While that would seem to offer middle ground, I see that as an added
> complexity in the build system that I would not want to maintain.
>
>
> I hereby declare discussion open regarding all these issues. Please keep the
> discussion on this list for now, and we will summarize the decisions in the
> bugs if appropriate.
>
> --
> Heikki Toivonen
>
>
>
More information about the Dev
mailing list