Re: [setup] Why does PackageSpecification have a private copy-constructor? (Robert?)

[Robert Collins]

On Mon, 2004-08-30 at 18:33 +0100, Max Bowsher wrote:
> I can't see why setup's PackageSpecification class has a private 
> copy-constructor.
> Am I missing something?

erm. to only allow the class itself to create copies.

> The reason why I am suddenly interested is that the C++ standard says that 
> this:
> 
> foo(SomeClass())
> 
> requires SomeClass's copy-constructor to be accessible (bizarre, no?) and 
> g++ 3.4 has decided to enforce this. 

Even if that is in a method:
SomeClass *
SomeClass::funkyCopy() const
{
  SomeClass *result(self);
}
?

> So, unless I can make the 
> copy-constructor public (which I don't want to do if doing so risks other 
> problems), I need to rewrite all code like:
> 
> do_something(PackageSpecification(somename))
> 
> to:
> 
> PackageSpecification tmppkgspec(somename);
> do_something(tmppkgspec);
> 
> which isn't very nice.

So we have code like that at the moment?

Rob


signature.asc
Description: This is a digitally signed message part

Re: [ITP] ocaml-3.08.1-1

[Yaakov Selkowitz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Igor Pechtchanski wrote:
| Hi all,
|
| I would like to contribute and maintain ocaml
| .
+1.
I tested the binary package by building lablgtk2 (gtk2 bindings) against
this, and it seems to work.  Package layout looks good, but I didn't try
building from source.
Yaakov
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFBM7k5piWmPGlmQSMRAigZAJ0a+ezTI51on9IujxBGFp5eSYai6gCePULE
RdbVlu9UYM2+AVUPvCKsY1g=
=s++M
-END PGP SIGNATURE-

Re: [ITP] pth-2.0.1-1, GNU Portable Threads

[Reini Urban]

Gerrit P. Haase schrieb:
I want to contribute and maintain pth, the GNU Portable Threads.
It builds without modifications since version 1.4 but I never got it
managed to get a shared library, finally I succeeded now to build it
with a DLL.  All tests are passing.
http://anfaenger.de/cygwin/cygwin-1.5/pth/README
http://anfaenger.de/cygwin/cygwin-1.5/pth/pth-2.0.1-1-src.tar.bz2
http://anfaenger.de/cygwin/cygwin-1.5/pth/pth-2.0.1-1.tar.bz2
http://anfaenger.de/cygwin/cygwin-1.5/pth/setup.hint
why did you rename aclocal.m4 to acinclude.m4 in the src package?
removing libtool.m4 is also unneccessary, since it's bypassed in your
configure.ac patch.
BTW: a cygwin case would be better
--- pth-2.0.1-orig/configure.ac 2004-07-13 12:48:16.0 +0200
+++ pth-2.0.1/configure.ac  2004-08-29 14:04:51.353214400 +0200
@@ -60,18 +60,7 @@
 AC_CHECK_DEBUGGING
 AC_CHECK_PROFILING
 AC_CHECK_OPTIMIZE
-if test -f "$srcdir/ltmain.sh"; then
-case "$PLATFORM" in
-#   Solaris 2.7/x86 is slightly broken
-*-pc-solaris2.[[78]] [)] enable_shared=no ;;
-esac
-sinclude(libtool.m4)
-AC_PROG_LIBTOOL
-else
-dnl # only for stripped down Pth source tree
-AC_CHECK_PROG(AR, ar, ar)
-AC_PROG_RANLIB
-fi
+AC_PROG_LIBTOOL
=>
AC_CHECK_DEBUGGING
AC_CHECK_PROFILING
AC_CHECK_OPTIMIZE
if test -f "$srcdir/ltmain.sh"; then
case "$PLATFORM" in
#   Solaris 2.7/x86 is slightly broken
*-pc-solaris2.[[78]] [)] enable_shared=no ;;
# cygwin has it's own (better) libtool.m4
*cygwin* | *mingw* ) ;;
* )
 sinclude(libtool.m4) ;;
esac
AC_PROG_LIBTOOL
else
dnl # only for stripped down Pth source tree
AC_CHECK_PROG(AR, ar, ar)
AC_PROG_RANLIB
fi
seems like a huge and unneded patch to me.
it's the same autoconf version 2.59 also.
CYGWIN-PATCHES/README has dos eol
the rest is okay.
BTW: where do you have the find_executable() patch from?
winsup/path.cc?
--
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: Can upset handle more than one prev: tag?

[Reini Urban]

Max Bowsher schrieb:
Reini Urban wrote:
Shouldn't we then provide a cygperl5_8.dll symlinked to cygperl5_8_5.dll
also (in linux fashion), and apps should link against cygperl5_8.dll
resp. a more generic libperl.dll.a then?
otherwise you'll have to recompile all dependent apps.
You are forgetting something. The Windows runtime linker 
(understandably) doesn't understand Cygwin symlinks. 
But cygwin dlopen does understand symlinks.
And perls dynalinker uses dlopen(cygpath),
not LoadLibrary (fullpath).
All other posix libs also use dlopen() not LoadLibrary().
And the cygwin dlopen() calls fullpath = get_full_path_of_dll(cygpath) 
which resolves links.

From what I've 
heard, perl tries to stay ABI-compatible throughout x.y.*, so the DLL 
should be named cygperl5_8.dll
--
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/