You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@stdcxx.apache.org by Martin Sebor <se...@roguewave.com> on 2007/09/12 00:20:46 UTC
Re: svn commit: r574618 - in /incubator/stdcxx/trunk: README configure.bat
generate.bat
Since this change affects a user interface to the library I think
we should provide a migration path for the transition to the new
interface. I suggest we keep generate.bat but make it a symbolic
link to configure.bat and deprecate it so that it can be removed
in 4.3.
Martin
faridz@apache.org wrote:
> Author: faridz
> Date: Tue Sep 11 07:39:54 2007
> New Revision: 574618
>
> URL: http://svn.apache.org/viewvc?rev=574618&view=rev
> Log:
> 2007-09-11 Farid Zaripov <Fa...@epam.com>
>
> STDCXX-516
> * generate.bat: File renamed ...
> * configure.bat: ... to this.
> README: "generate.bat" text replaced by "configure.bat".
>
> Added:
> incubator/stdcxx/trunk/configure.bat
> - copied unchanged from r574244, incubator/stdcxx/trunk/generate.bat
> Removed:
> incubator/stdcxx/trunk/generate.bat
> Modified:
> incubator/stdcxx/trunk/README
>
> Modified: incubator/stdcxx/trunk/README
> URL: http://svn.apache.org/viewvc/incubator/stdcxx/trunk/README?rev=574618&r1=574617&r2=574618&view=diff
> ==============================================================================
> --- incubator/stdcxx/trunk/README (original)
> +++ incubator/stdcxx/trunk/README Tue Sep 11 07:39:54 2007
> @@ -495,15 +495,15 @@
>
> o > CD stdlib-X.Y.Z-YYYYMMDD\stdlib
> > DIR /D # this is ${TOPDIR}
> - GNUmakefile etc examples generate.bat include src tests
> + GNUmakefile etc examples configure.bat include src tests
>
> If your distribution does not contain the test suite and/or the
> examples, the output will look like so:
>
> > DIR /D # this is ${TOPDIR}
> - GNUmakefile etc generate.bat include src
> + GNUmakefile etc configure.bat include src
>
> - o > .\generate.bat [/BUILDDIR:<builddir>] [/CONFIG:<config>]
> + o > .\configure.bat [/BUILDDIR:<builddir>] [/CONFIG:<config>]
>
> <builddir> is the pathname of the build directory where to create
> the solution and projects; the directory will be
> @@ -532,7 +532,7 @@
> automatically.
>
> o Example:
> - > generate.bat /BUILDDIR:C:\stdcxx /CONFIG:msvc-7.1
> + > configure.bat /BUILDDIR:C:\stdcxx /CONFIG:msvc-7.1
>
> This command will create a build directory rooted at ${BUILDDIR},
> the solution file ${BUILDDIR}\msvc-7.1\msvc-7.1.sln, the project
>
>
Re: svn commit: r574618 - in /incubator/stdcxx/trunk: README configure.bat
generate.bat
Posted by Martin Sebor <se...@roguewave.com>.
Andrew, since we discussed merging Farid's change out to 4.2,
I think it would be best to wait until the transient symlink
is in place.
Martin
Martin Sebor wrote:
> Since this change affects a user interface to the library I think
> we should provide a migration path for the transition to the new
> interface. I suggest we keep generate.bat but make it a symbolic
> link to configure.bat and deprecate it so that it can be removed
> in 4.3.
>
> Martin
>
> faridz@apache.org wrote:
>> Author: faridz
>> Date: Tue Sep 11 07:39:54 2007
>> New Revision: 574618
>>
>> URL: http://svn.apache.org/viewvc?rev=574618&view=rev
>> Log:
>> 2007-09-11 Farid Zaripov <Fa...@epam.com>
>>
>> STDCXX-516
>> * generate.bat: File renamed ...
>> * configure.bat: ... to this.
>> README: "generate.bat" text replaced by "configure.bat".
>>
>> Added:
>> incubator/stdcxx/trunk/configure.bat
>> - copied unchanged from r574244,
>> incubator/stdcxx/trunk/generate.bat
>> Removed:
>> incubator/stdcxx/trunk/generate.bat
>> Modified:
>> incubator/stdcxx/trunk/README
>>
>> Modified: incubator/stdcxx/trunk/README
>> URL:
>> http://svn.apache.org/viewvc/incubator/stdcxx/trunk/README?rev=574618&r1=574617&r2=574618&view=diff
>>
>> ==============================================================================
>>
>> --- incubator/stdcxx/trunk/README (original)
>> +++ incubator/stdcxx/trunk/README Tue Sep 11 07:39:54 2007
>> @@ -495,15 +495,15 @@
>>
>> o > CD stdlib-X.Y.Z-YYYYMMDD\stdlib
>> > DIR /D # this is ${TOPDIR}
>> - GNUmakefile etc examples generate.bat include src tests
>> + GNUmakefile etc examples configure.bat include src tests
>>
>> If your distribution does not contain the test suite and/or the
>> examples, the output will look like so:
>>
>> > DIR /D # this is ${TOPDIR}
>> - GNUmakefile etc generate.bat include src
>> + GNUmakefile etc configure.bat include src
>>
>> - o > .\generate.bat [/BUILDDIR:<builddir>] [/CONFIG:<config>]
>> + o > .\configure.bat [/BUILDDIR:<builddir>] [/CONFIG:<config>]
>>
>> <builddir> is the pathname of the build directory where to create
>> the solution and projects; the directory will be
>> @@ -532,7 +532,7 @@
>> automatically.
>>
>> o Example:
>> - > generate.bat /BUILDDIR:C:\stdcxx /CONFIG:msvc-7.1
>> + > configure.bat /BUILDDIR:C:\stdcxx /CONFIG:msvc-7.1
>>
>> This command will create a build directory rooted at ${BUILDDIR},
>> the solution file ${BUILDDIR}\msvc-7.1\msvc-7.1.sln, the project
>>
>>
>
Re: svn commit: r574618 - in /incubator/stdcxx/trunk: README configure.bat
generate.bat
Posted by Martin Sebor <se...@roguewave.com>.
Farid Zaripov wrote:
>> -----Original Message-----
>> From: Martin Sebor [mailto:sebor@roguewave.com]
>> Sent: Wednesday, September 12, 2007 6:01 PM
>> To: stdcxx-dev@incubator.apache.org
>> Subject: Re: svn commit: r574618 - in
>> /incubator/stdcxx/trunk: README configure.bat generate.bat
>>
>>> AFAIK the svn-client not support symbolic links on windows.
>> I thought the file would end up getting copied on Windows.
>> That's what Perforce does (which is probably why I thought
>> that). If it doesn't, why don't we create a wrapper
>> generate.bat script and invoke configure.bat from it as the
>> temporary solution.
>
> I will create it.
Great, thanks.
>
>>> Because of that the filebuf example always fail with DIFF
>> status on
>>> my workstation (the manual/out/filebuf.out is a symbolic link to
>>> manual/filebuf.cpp, but on windows the content of this file is just
>>> single line: "link ../filebuf.cpp").
>>>
>>> I surprized how this example runs with status 0 in nightly builds.
>> You think there's a problem there?
>
> I think there no problem when user downloads the stdcxx library in
> archive.
>
> When I downloaded the 4.1.3 release
> (http://cvs.apache.org/dist/incubator/stdcxx/releases/stdcxx-incubating-
> 4.1.3.tar.gz)
> and extracted it, the filebuf.out is correctly copied from filebuf.cpp
> by
> archiver (I have used WinRAR).
Right, that's probably because tar on Windows must be smart enough
replace symlinks with the files they point to, if they point within
the tarball.
So the problem only occurs when someone checks out the repository
on Windows. Subversion should know to do the same thing as Perforce
on Windows instead of expanding the contents of the link. This seems
like an svn bug or at least a bad limitation. I'm not sure there's
anything we can do about it short of avoiding symlinks.
Martin
RE: svn commit: r574618 - in /incubator/stdcxx/trunk: README configure.bat generate.bat
Posted by Farid Zaripov <Fa...@epam.com>.
> -----Original Message-----
> From: Martin Sebor [mailto:sebor@roguewave.com]
> Sent: Wednesday, September 12, 2007 6:01 PM
> To: stdcxx-dev@incubator.apache.org
> Subject: Re: svn commit: r574618 - in
> /incubator/stdcxx/trunk: README configure.bat generate.bat
>
> > AFAIK the svn-client not support symbolic links on windows.
>
> I thought the file would end up getting copied on Windows.
> That's what Perforce does (which is probably why I thought
> that). If it doesn't, why don't we create a wrapper
> generate.bat script and invoke configure.bat from it as the
> temporary solution.
I will create it.
> > Because of that the filebuf example always fail with DIFF
> status on
> > my workstation (the manual/out/filebuf.out is a symbolic link to
> > manual/filebuf.cpp, but on windows the content of this file is just
> > single line: "link ../filebuf.cpp").
> >
> > I surprized how this example runs with status 0 in nightly builds.
>
> You think there's a problem there?
I think there no problem when user downloads the stdcxx library in
archive.
When I downloaded the 4.1.3 release
(http://cvs.apache.org/dist/incubator/stdcxx/releases/stdcxx-incubating-
4.1.3.tar.gz)
and extracted it, the filebuf.out is correctly copied from filebuf.cpp
by
archiver (I have used WinRAR).
Farid.
Re: svn commit: r574618 - in /incubator/stdcxx/trunk: README configure.bat
generate.bat
Posted by Martin Sebor <se...@roguewave.com>.
Farid Zaripov wrote:
>> -----Original Message-----
>> From: Martin Sebor [mailto:sebor@roguewave.com]
>> Sent: Wednesday, September 12, 2007 3:43 AM
>> To: stdcxx-dev@incubator.apache.org
>> Subject: Re: svn commit: r574618 - in
>> /incubator/stdcxx/trunk: README configure.bat generate.bat
>>
>> You're probably right, but adding the link is cheap and, IMO,
>> worth the peace of mind that we won't be breaking anyone's
>> code, no matter how unlikely the breakage is. Plus, it will
>> give us the opportunity to exercise our deprecation policy! ;-)
>
>
> AFAIK the svn-client not support symbolic links on windows.
I thought the file would end up getting copied on Windows. That's
what Perforce does (which is probably why I thought that). If it
doesn't, why don't we create a wrapper generate.bat script and
invoke configure.bat from it as the temporary solution.
> Because of that the filebuf example always fail with DIFF status on my
> workstation
> (the manual/out/filebuf.out is a symbolic link to manual/filebuf.cpp,
> but on windows
> the content of this file is just single line: "link ../filebuf.cpp").
>
> I surprized how this example runs with status 0 in nightly builds.
You think there's a problem there?
Martin
Re: svn commit: r574618 - in /incubator/stdcxx/trunk: README configure.bat
generate.bat
Posted by Martin Sebor <se...@roguewave.com>.
Andrew Black wrote:
> Martin Sebor wrote:
>> Come to think of it, aren't we already using tar and gzip to
>> package up our builds? Andrew, can we switch to tar/gzip for
>> our sources as well?
>
> No. We still package the post-build archives on windows using jar, and
> I don't think the nightly testing system is capable of handling tar/gzip
> or tar/bzip source archives.
It's a bug/limitation then. Let me open a request to get it
fixed sometime in the next decade.
Martin
Re: svn commit: r574618 - in /incubator/stdcxx/trunk: README configure.bat
generate.bat
Posted by Andrew Black <ab...@roguewave.com>.
Martin Sebor wrote:
> Come to think of it, aren't we already using tar and gzip to
> package up our builds? Andrew, can we switch to tar/gzip for
> our sources as well?
No. We still package the post-build archives on windows using jar, and
I don't think the nightly testing system is capable of handling tar/gzip
or tar/bzip source archives.
--Andrew Black
Re: svn commit: r574618 - in /incubator/stdcxx/trunk: README configure.bat
generate.bat
Posted by Martin Sebor <se...@roguewave.com>.
Come to think of it, aren't we already using tar and gzip to
package up our builds? Andrew, can we switch to tar/gzip for
our sources as well?
Martin
Martin Sebor wrote:
> Andrew Black wrote:
>> Farid Zaripov wrote:
>> [snip]
>>> Because of that the filebuf example always fail with DIFF status on my
>>> workstation
>>> (the manual/out/filebuf.out is a symbolic link to manual/filebuf.cpp,
>>> but on windows
>>> the content of this file is just single line: "link ../filebuf.cpp").
>>>
>>> I surprized how this example runs with status 0 in nightly builds.
>>>
>>> Farid.
>>
>> Greetings Farid.
>>
>> The reason the filebuf test succeeds in nightly testing is an artifact
>> of the build process. The sources are synced down on a linux system,
>> and then compressed using the jar utility. This compressed archive is
>> then expanded by the nightly testing system when a build is performed.
>> Somewhere during this process, the symlink (on unix) is turned into a
>> real file, containing the expected input.
>
> Yet another problem caused (or masked in this case) by using jar...
>
> Martin
Re: svn commit: r574618 - in /incubator/stdcxx/trunk: README configure.bat
generate.bat
Posted by Martin Sebor <se...@roguewave.com>.
Andrew Black wrote:
> Farid Zaripov wrote:
> [snip]
>> Because of that the filebuf example always fail with DIFF status on my
>> workstation
>> (the manual/out/filebuf.out is a symbolic link to manual/filebuf.cpp,
>> but on windows
>> the content of this file is just single line: "link ../filebuf.cpp").
>>
>> I surprized how this example runs with status 0 in nightly builds.
>>
>> Farid.
>
> Greetings Farid.
>
> The reason the filebuf test succeeds in nightly testing is an artifact
> of the build process. The sources are synced down on a linux system,
> and then compressed using the jar utility. This compressed archive is
> then expanded by the nightly testing system when a build is performed.
> Somewhere during this process, the symlink (on unix) is turned into a
> real file, containing the expected input.
Yet another problem caused (or masked in this case) by using jar...
Martin
Re: svn commit: r574618 - in /incubator/stdcxx/trunk: README configure.bat
generate.bat
Posted by Andrew Black <ab...@roguewave.com>.
Farid Zaripov wrote:
[snip]
>
> Because of that the filebuf example always fail with DIFF status on my
> workstation
> (the manual/out/filebuf.out is a symbolic link to manual/filebuf.cpp,
> but on windows
> the content of this file is just single line: "link ../filebuf.cpp").
>
> I surprized how this example runs with status 0 in nightly builds.
>
> Farid.
Greetings Farid.
The reason the filebuf test succeeds in nightly testing is an artifact
of the build process. The sources are synced down on a linux system,
and then compressed using the jar utility. This compressed archive is
then expanded by the nightly testing system when a build is performed.
Somewhere during this process, the symlink (on unix) is turned into a
real file, containing the expected input.
--Andrew Black
RE: svn commit: r574618 - in /incubator/stdcxx/trunk: README configure.bat generate.bat
Posted by Farid Zaripov <Fa...@epam.com>.
> -----Original Message-----
> From: Martin Sebor [mailto:sebor@roguewave.com]
> Sent: Wednesday, September 12, 2007 3:43 AM
> To: stdcxx-dev@incubator.apache.org
> Subject: Re: svn commit: r574618 - in
> /incubator/stdcxx/trunk: README configure.bat generate.bat
>
> You're probably right, but adding the link is cheap and, IMO,
> worth the peace of mind that we won't be breaking anyone's
> code, no matter how unlikely the breakage is. Plus, it will
> give us the opportunity to exercise our deprecation policy! ;-)
AFAIK the svn-client not support symbolic links on windows.
>From http://subversion.tigris.org/ :
---------
# Versioning of symbolic links
Unix users can place symbolic links under version control. The links are
recreated in Unix working copies, but not in win32 working copies.
---------
Another source http://svnbook.red-bean.com/en/1.1/ch07s02.html :
---------
svn:special
The svn:special property is the only svn: property that isn't meant to
be directly set or modified by users. Subversion automatically sets this
property whenever a "special" object is scheduled for addition, such as
a symbolic link. The repository stores an svn:special object as an
ordinary file. However, when a client sees this property during
checkouts or updates, it interprets the contents of the file and
translates the item back into the special type of object. In Subversion
1.1, only versioned symbolic links have this property attached, but in
future versions of Subversion other special types of nodes will probably
use this property as well.
Note: Windows clients don't have symbolic links, and thus ignore any
svn:special files coming from a repository that claim to be symbolic
links. On Windows, the user ends up with an ordinary versioned file in
the working copy.
---------
Because of that the filebuf example always fail with DIFF status on my
workstation
(the manual/out/filebuf.out is a symbolic link to manual/filebuf.cpp,
but on windows
the content of this file is just single line: "link ../filebuf.cpp").
I surprized how this example runs with status 0 in nightly builds.
Farid.
Re: svn commit: r574618 - in /incubator/stdcxx/trunk: README configure.bat
generate.bat
Posted by Martin Sebor <se...@roguewave.com>.
Eric Lemings wrote:
>
>> -----Original Message-----
>> From: Martin Sebor [mailto:sebor@roguewave.com]
>> Sent: Tuesday, September 11, 2007 4:21 PM
>> To: stdcxx-dev@incubator.apache.org
>> Subject: Re: svn commit: r574618 - in
>> /incubator/stdcxx/trunk: README configure.bat generate.bat
>>
>> Since this change affects a user interface to the library I think
>> we should provide a migration path for the transition to the new
>> interface. I suggest we keep generate.bat but make it a symbolic
>> link to configure.bat and deprecate it so that it can be removed
>> in 4.3.
>>
>> Martin
>
> Migration paths are almost always A Good Thing and I agree: a link is a
> good idea. However, I just want to point out that these Windows files
> were only present in one whole release of STDCXX. I doubt backward
> compatibility is a serious hurdle in this particular case. :-P
You're probably right, but adding the link is cheap and, IMO, worth
the peace of mind that we won't be breaking anyone's code, no matter
how unlikely the breakage is. Plus, it will give us the opportunity
to exercise our deprecation policy! ;-)
Martin
RE: svn commit: r574618 - in /incubator/stdcxx/trunk: README configure.bat generate.bat
Posted by Eric Lemings <le...@roguewave.com>.
> -----Original Message-----
> From: Martin Sebor [mailto:sebor@roguewave.com]
> Sent: Tuesday, September 11, 2007 4:21 PM
> To: stdcxx-dev@incubator.apache.org
> Subject: Re: svn commit: r574618 - in
> /incubator/stdcxx/trunk: README configure.bat generate.bat
>
> Since this change affects a user interface to the library I think
> we should provide a migration path for the transition to the new
> interface. I suggest we keep generate.bat but make it a symbolic
> link to configure.bat and deprecate it so that it can be removed
> in 4.3.
>
> Martin
Migration paths are almost always A Good Thing and I agree: a link is a
good idea. However, I just want to point out that these Windows files
were only present in one whole release of STDCXX. I doubt backward
compatibility is a serious hurdle in this particular case. :-P
EBL