have forwards and
backwards binary compatibility.
* Changes destined for the 4.3.x branch should have backwards source
compatibility.
--Andrew Black
On 02/03/2012 03:04 PM, Farid Zaripov wrote:
On 03.02.2012 1:52, Stefan Teleman wrote:
2. Someone with stdcxx commit privileges should be pa
ust be met for this
to happen.
--Andrew Black
On 02/02/2012 12:03 PM, William A. Rowe Jr. wrote:
Fans and contributors,
it appears that the stdcxx project is entirely dormant. The ASF has
launched a new 'Attic' project over the past two years, to neatly
retire dormant works until an
+1
While it appears that there is some traffic on the wiki page
(documenting compiler support for various STDCXX 0X features), no effort
is being undertaken to update the library to support these features.
On 02/02/2012 12:03 PM, William A. Rowe Jr. wrote:
Fans and contributors,
it appears
, Service Pack 1,
using vacpp-10.1.
--Andrew Black
t-msvc-9.0-*-*-log.gz.txt" \
> win_vista_0-em64t-msvc-9.0.html
>
That looks correct. As I said, I've added the required translation to
fetch_records.pl (one of the scripts run on the RogueWave side of
things), so we may be able to get by with just adding
process_results "Win
If the changes aren't automatically propagated, we'll
likely need to figure out how to transition the push updates to my user
account.
The second correction is that the testing coverage on windows-2008
includes MSVC 8.0.
--Andrew Black
Martin Sebor wrote:
> Thanks for the heads up! I upd
ed to push the
results out to apache has not been updated with the new versions.
--Andrew Black
to manually perform the export, splitting the export list into
pieces to avoid overloading scp. You'll then need to manually update
the cache file as is done at the end of static_export.sh.
--Andrew Black
Martin Sebor wrote:
> The page has been updated but it looks like all the builds a
aren't telling me much. When I manually sent a kill message to the
tests in question, it was sufficient to send a SIGTERM.
--Andrew Black
warning: -A: ignoring unimplemented compatibility mode option
warning: -C: ignoring unimplemented compatibility mode option
warning: -D: ignoring unimple
limit.
If there are resource limits being set, try re-running the export
manually without setting any. It's been long enough since we had a
'good' export that you'll end up dumping essentially all the current
results from the system.
--Andrew Black
Martin Sebor wrote:
> It
e in this script to reflect the change. Looking at
the timestamp for the script, it looks like it's automatically updated
as part of the export process, so with a little luck we'll get a good
export tomorrow.
--Andrew Black
se the legacy test
suite (from //stdcxx/trunk/tests/...) depend on them. Once porting of
the test suite is complete, the dependencies on perforce will go away.
--Andrew Black
>
> Brad.
Martin Sebor wrote:
> Is everyone here subscribed to [EMAIL PROTECTED] or should
> I continue to forward these updates?
I'm subscribed, so no need to forward the messages on my part.
--Andrew Black
on a windows
system (with the output using windows line endings).
My solution (attached) removes the checks on the return from fread, and
saves that value in the readback structure as the pointer into the read
buffer.
--Andrew Black
Eric Lemings wrote:
>
> Does this mean we have no solutio
ed. This
particular build occurred after
http://svn.apache.org/viewvc?rev=643120&view=rev was checked in (my
resolution for STDCXX-426), but before Farid's change (
http://svn.apache.org/viewvc?rev=644314&view=rev ) was checked in.
--Andrew Black
Martin Sebor wrote:
> Looks like all ex
, but the options required to limit the
output to some number of bytes appear to vary from platform to platform,
so you'd have to change the flags used to conform to the platform. This
could be done in the nightly testing glue scripts.
--Andrew Black
Martin Sebor wrote:
> [EMAIL PROTECTED] wrote:
>> Author: ablack
>> Date: Tue Apr 1 08:36:22 2008
>> New Revision: 643448
>>
>> URL: http://svn.apache.org/viewvc?rev=643448&view=rev
>> Log:
>> 2008-04-01 Andrew Black <[EMAIL PROTECTED]&
f the
build tree. One of the options passed to the target is the PREFIX
variable, defining where the installation is to be performed to. The
other option which can be passed is LOCALES, defining the list of
locales to install.
--Andrew Black
Eric Lemings wrote:
> After reproducing and obser
complex logic to determine whether the path
should be prepended to LD_LIBRARY_PATH, LD_LIBRARY_PATH_64, SHLIBPATH,
DYLDPATH, or some other platform-dependent environment variable.
--Andrew Black
Eric Lemings wrote:
>
> Could someone give an example of the failures described by this issue
Martin Sebor wrote:
> Farid Zaripov wrote:
[snip]
>> But anyway maybe it makes sense to schedule the builds on the same
>> machine to not run at the same time?
The scheduling system doesn't allow for the concept of mutually
exclusive requests/runs, meaning only one build of X can be running at a
user wish to perform a
purify enabled build (unless specified otherwise, such as with the
WITHOUT_PURIFY switch).
--Andrew Black
21 matches
Mail list logo
