[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