On 6 July 2006 at 21:37, Gregory Shimansky <[EMAIL PROTECTED]> wrote: > On Thursday 06 July 2006 20:20 Tim Ellison wrote: > > Gregory Shimansky wrote: > > > On Thursday 06 July 2006 03:46 Geir Magnusson Jr wrote: > > >> In HARMONY-681, I applied the patch to build DRLVM as debug by default, > > >> but 'rejected' the classlib patch, as it's not overridable as the DRLVM > > >> one is. > > >> > > >> I think that we'd like to be able to set a flag for release build, > > >> rather than have to rummage about in each makefile and include. > > >> > > >> Yea? Nea? > > > > > > +1 for release flag when it is needed > > > > > > I support this as I also think that current classlib build system > > > is rather primitive > > Btw no offense intended I meant only native part of the build > system. Java part is fine to me.
None taken. Personally, I think "primitive" in the sense of not yet evolved is precisely what it is. At the moment, it does the job. However, I've hacked the CFLAGS more than once so it's definitely time it evolved a little. > I think I didn't understand the original question well enough. Sure > I think it would be good to have more than one mode to build native > sources. > > > Don't mistake being simple with being primitive <g>. It will need > > to grow as we expand the amount of platform-dependent code, but I > > suggest we try to keep things as simple as possible. > > > > > which is easy to alter by developers locally but isn't really > > > meant to be a product build system. > > > > What do you mean? > > (I'll try to answer both your and Geir's question here) > > The build system for native code is really simple and has most things > like even debug on/off mode hardcoded in the flags. It has just one > fixed set of flags which don't include debug by default. If any change > is required, makefiles have to be changed and I am sure I am not alone > who altered them locally to produce debug version. Can you describe how you've been altering them? It would be good to understand what requirements you might have. I've only ever added flags never removed them. Would hy.native.cflags and hy.native.ldflags defined in ant (defaulting to -g but being settable with -D) being added to the make environment and ultimately added to the existing flags be sufficient. Or do you have more requirements? Incidentally, I think it should already be possible to set environment variables to override any of the flags since ant is passing the entire environment to the make call and environment variables take priority. This is ugly though and we should find a more elegant solution. > I think we'll come to some sort of configure script but maybe not, it > should be discussed separately. I think we may end up there too. We might even evolve from ant to maven. (/me waits to see if Geir will take the bait. ;-) But I don't think we should rush to make changes before there is a compelling demand for them. > I agree that we need to improve it and add more flexible control > over what it can produce, debug/release, different architectures, > optimizations, maybe compilers. But discussing on the direction which > this process should take (e.g. we may agree to add a configure script) > may take a long time while a simple change to enable debugging by > default doesn't since it seems most of the people agree that it is > right thing to do. Agreed. Patches welcome. ;-) Or you could just elaborate on your requirements and I might take a shot at it. Regards, Mark. --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
