I think we should do this. However, this will "break" developers using
the IBM VME. Perhaps we could do:
Index: make/properties.xml
===================================================================
--- make/properties.xml (revision 805151)
+++ make/properties.xml (working copy)
@@ -286,7 +286,10 @@
<property name="exclude.module" value="nothing" />
<!-- flags -->
- <property name="hy.no.thr" value="false" />
+ <condition property="hy.no.thr" value="false">
+ <available file="${hy.hdk}/jdk/jre/bin/default/libj9vm23.so" />
+ </condition>
+ <property name="hy.no.thr" value="true" />
<condition property="hy.skip.thr" value="true">
<not>
<equals arg1="${hy.no.thr}" arg2="false" />
to mitigate this slightly?
Regards,
Mark.
In message <4a8a7b91.6090...@googlemail.com>, Oliver Deakin writes:
>
> Carrying on from this discussion, I'd like to make hy.no.thr=true the
> default setting and stop building the classlib thread library in the
> federated build.
>
> Please let me know if there are any objections/comments on this,
> otherwise I will make the change after M11 is published.
>
> Regards,
> Oliver
>
> Oliver Deakin wrote:
> > Mark Hindess wrote:
> >> In message
> >> <94d710af0908112202x6eb5498dy9bd1dd84dbdde...@mail.gmail.com>,
> >> Sean Qiu writes:
> >>
> >>> +1 for both of your proposal, it sounds reasonable and cool.
> >>> Thanks, Oli.
> >>>
> >>
> >> I am in favour of removing the option completely and removing the
> >> classlib thread code. Of course, this breaks the IBM VME so perhaps we
> >> can leave it in place - but change the default? - until a new IBM VME is
> >> available?
> >>
> > Yes, I think we should switch the default to hy.no.thr=true for a
> > transition period. There is no harm in keeping the classlib thread
> > code present for a while, but I think the eventual goal should be to
> > delete it from the repo.
> >
> >>
> >>> One question here, what do you mean remove the code? svn del?
> >>> What about we "svn move" it to some other place, such as
> >>>
> >>> https://svn.apache.org/repos/asf/harmony/enhanced/legacy
> >>>
> >>
> >> Well, we already have:
> >>
> >> https://svn.apache.org/repos/asf/harmony/enhanced/classlib/archive
> >>
> >> but I think "svn delete" is fine since you can always checkout earlier
> >> revisions if you need to revisit the code.
> >>
> >
> > Agreed.
> >
> > Regards,
> > Oliver
> >
> >> Regards,
> >> Mark.
> >>
> >>
> >>> 2009/8/11 Oliver Deakin <oliver.dea...@googlemail.com>:
> >>>
> >>>> Hi all,
> >>>>
> >>>> I have added an implementation of the thread library function table
> >>>> for
> >>>> DRLVM which can be enabled by building with the "-Dhy.no.thr=true"
> >>>> flag
> >>>> specified on the Ant command line. This means we no longer need to
> >>>> build th
> >>>>
> >>> e
> >>>
> >>>> classlib thread library in the federated build, and we also no
> >>>> longer need
> >>>> to copy the DRLVM hythr library into jre/bin (although I havn't
> >>>> changed the
> >>>> build to not do the copy yet). I have temporarily set the hythr
> >>>> library
> >>>> version to 0.2 so that the federated build can be run with and
> >>>> without the
> >>>> hy.no.thr flag set.
> >>>>
> >>>> This opens a couple of questions for discussion:
> >>>> 1) Shall we set the hy.no.thr option to true as default? I
> >>>> personally think
> >>>> we should - the classlib hythr library is not used in the federated
> >>>> builds,
> >>>> so there is no reason to continue building it.
> >>>> 2) Shall we remove the thread library from classlib altogether? If
> >>>> hy.no.thr=true becomes the default, I can see reasons for and
> >>>> against [1]
> >>>> removing the source from classlib, but I think the reasons to
> >>>> remove the
> >>>> code outweigh the reasons to keep it. My vote is to remove that source
> >>>> module from classlib altogether.
> >>>>
> >>>> Ideas/comments?
> >>>>
> >>>> Regards,
> >>>> Oliver
> >>>>
> >>>> [1] A few I can think of straight off:
> >>>> For:
> >>>> - Unused thread library code in classlib is unlikely to be maintained.
> >>>> - Some classlib thread code is incorrect (x86_64 linux has some
> >>>> invalid
> >>>> assembler code I believe).
> >>>> - Shrinks the source tree footprint.
> >>>> - All VMs will likely have their own implementation of this
> >>>> functionality
> >>>> anyway.
> >>>> Against:
> >>>> - Raises the bar slightly for VM vendors wishing to use the Harmony
> >>>> class
> >>>> libraries.
> >>>>
> >>
> >>
> >>
> >>
> >
>
> --
> Oliver Deakin
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number 7415
> 98.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
>
