Open Watcom v2.0
Peter C. Chapin
for a release of Open Watcom v2.0 in about six months. That means March
2012. I don't anticipate 2.0 being much different than 1.9. Indeed, as it
stands right now the delta between 1.9 and 2.0beta might be less than
that between most adjacent releases. However, I don't think that's a
problem and I don't want to go too long between releases in any case. As
it is 2.0 will be almost two years after 1.9.
Anyway, I'm posting this to let people know. If there is anything burning
you need in 2.0 that isn't already in the trunk try to get it committed
in the next few months. My proposed release date is also subject to
change so that could be done also if necessary.
Past experience shows that we typically consume a couple of months (or
more) on release candidates. Maybe it will be less this time if 2.0 is a
relatively small change from 1.9. However, I don't want to assume
anything. Thus I'll plan on publishing RC1 some time in January. I think
I can manage to make that work. Hopefully that will be ok for others as
well.
Peter
Leif Ekblad
target. If this option is enabled in flags.mif, clib will not build with the
1.9 compiler (only with the compiler generated before in the build).
Additionally, if clib for rdosdev is not built with -zdp flag, it really
won't work as it trashes DS. I have locally enabled the -zdp option in order
to debug this target, but I cannot commit this change.
Leif Ekblad
Peter C. Chapin
I don't like the idea that 2.0 can't be built with 1.9 out of the box
without special handling (specifically, manual editing) of certain files
between the two phases. Here "phase one" is the compilation of 2.0 with
1.9 and then "phase two" is the full rebuild of 2.0 with 2.0. I always
do these two phases when preparing a release.
So is it not possible to make the final build without manually editing
files between phase one and phase two? If so that's a significant issue.
Perhaps it's not a big deal if it only affects RDOS. I'm sure very few
people attempt these builds once the release is finished and even fewer
of them would be following the RDOS support. Still... is there a better way?
Peter
Leif Ekblad
> I don't like the idea that 2.0 can't be built with 1.9 out of the box
> without special handling (specifically, manual editing) of certain files
> between the two phases. Here "phase one" is the compilation of 2.0 with
> 1.9 and then "phase two" is the full rebuild of 2.0 with 2.0. I always do
> these two phases when preparing a release.
>
> So is it not possible to make the final build without manually editing
> files between phase one and phase two? If so that's a significant issue.
> Perhaps it's not a big deal if it only affects RDOS. I'm sure very few
> people attempt these builds once the release is finished and even fewer of
> them would be following the RDOS support. Still... is there a better way?
It is only the RDOS source that won't build as the -zdp option is added to
clib. OTOH, a full build would also build RDOS, so the full build would
become broken. The reason for this is that the 1.9 C-compiler have errors
in intrinsic functions (it tries to use DS as a parameter, which is not
allowed with zdp).
Maybe we could add the -zdp option after RC1, and then there would
be a need to do a full build with RC1 instead of 1.9 up until 2.0 is
released?
Alternatively, there is a need to build the C-compiler before clib is built,
and
then to use the new C compiler to compile clib.
Leif Ekblad
Peter C. Chapin
> Maybe we could add the -zdp option after RC1, and then there would
> be a need to do a full build with RC1 instead of 1.9 up until 2.0 is
> released?
>
> Alternatively, there is a need to build the C-compiler before clib is built,
> and then to use the new C compiler to compile clib.
I'm not completely against manually editing a file between phases as
long as it's a simple change. Perhaps we should bring Michal into this
conversation. I'll send him a note.
Peter