X-Recipient:	archive-cygwin AT delorie DOT com
DKIM-Filter:	OpenDKIM Filter v2.11.0 sourceware.org 4E51D386F81D
DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com;
	s=default; t=1605865077;
	bh=olItj1jHJXIq1i8/paZ6UV1K4TdtPruIVQzrFm+woZo=;
	h=To:References:In-Reply-To:Subject:Date:List-Id:List-Unsubscribe:
	List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:
	From;
	b=AqugsQZD213iLdUpAm7Q8EhbTEi1CyPIXEj6Z2oWN2o6p9SzB/5PTwe3rmQP7MSZJ
	kywXsYdQjloOXpG/lLFUgVd9Z6gtEhQflOJ5/0xLtjpA5WZZ8bgz0nt7cuB932CLSz
	dAuz41zGL757zKEqf1PrlWL8Izcqq2m/SirbOce8=
X-Original-To:	cygwin AT cygwin DOT com
Delivered-To:	cygwin AT cygwin DOT com
DMARC-Filter:	OpenDMARC Filter v1.3.2 sourceware.org 335D6386F81D
X-Google-DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:from:to:references:in-reply-to:subject:date
	:message-id:mime-version:content-transfer-encoding:content-language
	:thread-index;
	bh=MvIKNAaG3TU9/yHZImR6fk9xwjTnt0B0ZrpwTk3mxr0=;
	b=uULiuuGJtt/iYVcc9KXHkfRefUUbRZXVpWMcfBXAJuGivvq8rGt5DKAAIHnFNDQaqV
	sQzlsWFypGw6PeGyaauUiZSF7ZRxreNAI9TglcceWDpLAHWteRd+0klP8OrC3fWlIoVi
	6aJFQL7KGD3BSspYkN36P+ervb9SMomVH2Kl2KTF6Eio1UhEk5b93c6R0irZ5Ko2g4rd
	TWH92q/AuJf8Qydr/5c6L5yliidTijBbFnZMpt1FaXdmr3UyLz3i/WY2EpNs47dCmmK2
	ApAflW9e+E3DQNAyds3WNtUvA1y2Bk5xvWHmdVruExNV48kgG8U7fz3H92ZHEJzr5oET
	badw==
X-Gm-Message-State:	AOAM533rbtXrxQh8ZZqmQ8xoRWTXlmKJt9aYY3tMUtGDRI+KHqWCadSj
	hwIwMwo2xvftPt6afs4/yR5TCMnJ/hs=
X-Google-Smtp-Source:	ABdhPJxAdwqMYpcPye9BSCoNVvs9ifdsNukTK9Dl9Inultzpfv8X9mA4xOlJlZVshQx3mCpz3gTv1g==
X-Received:	by 2002:a2e:b536:: with SMTP id z22mr7804983ljm.177.1605865072525;
	Fri, 20 Nov 2020 01:37:52 -0800 (PST)
To:	<cygwin AT cygwin DOT com>
References:	<c2d6280c-26e3-f9e7-89bd-693385a768b2 AT gmail DOT com>
	<D3704C33-A283-40F0-990D-CB9806F0B09D AT gmail DOT com>
	<000a01d6be5b$3808cad0$a81a6070$@gmail.com>
	<15d2b3e5-cbb8-0008-e99a-3922ff4a5f3b AT SystematicSw DOT ab DOT ca>
In-Reply-To:	<15d2b3e5-cbb8-0008-e99a-3922ff4a5f3b@SystematicSw.ab.ca>
Subject:	Sv: Sv: g++ and c++17 filesystem
Date:	Fri, 20 Nov 2020 10:37:51 +0100
Message-ID:	<000801d6bf20$d0ce0670$726a1350$@gmail.com>
MIME-Version:	1.0
X-Mailer:	Microsoft Outlook 16.0
Thread-Index:	AQIMEcHDzo+EBBrhHHj3sFlr53GwtQIBqNbVAy9h9QUBKn/4X6kzNpzQ
X-Spam-Status:	No, score=-3.2 required=5.0 tests=BAYES_00, DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,
	SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2
X-Spam-Checker-Version:	SpamAssassin 3.4.2 (2018-09-13) on
	server2.sourceware.org
X-BeenThere:	cygwin AT cygwin DOT com
X-Mailman-Version:	2.1.29
List-Id:	General Cygwin discussions and problem reports <cygwin.cygwin.com>
List-Archive:	<https://cygwin.com/pipermail/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-request AT cygwin DOT com?subject=help>
List-Subscribe:	<https://cygwin.com/mailman/listinfo/cygwin>,
	<mailto:cygwin-request AT cygwin DOT com?subject=subscribe>
From:	Kristian Ivarsson via Cygwin <cygwin AT cygwin DOT com>
Reply-To:	sten DOT kristian DOT ivarsson AT gmail DOT com
Sender:	"Cygwin" <cygwin-bounces AT cygwin DOT com>
X-MIME-Autoconverted:	from base64 to 8bit by delorie.com id 0AK9cLGB013368

[snip]
> >> As stated earlier, it seems like using mingw g++/libstdc++ (from the
> >> cygwin-package-manager) it seems like it works better, but then you
> >> can’t mix with other posix/cygwin mechanism (that uses cygstdc++)
> >> without breaking ODR (and probably some memory models etc as well) so
> >> maybe someone do have some insightful info about this ? How “special”
> >> is
> >> cygstdc++ (compared to mingw:s libstdc++) ? Could this be fixable in
> >> cygstdc++ that
> >> library (cygstdc++) ?


> > I might be totally wrong, so does anyone have any take on this ?
> 
> Cygwin provides cross-tools like djgpp-gcc-core mingw64-i686-gcc-core,
> mingw64-x86_64-gcc-core, cygwin32-gcc-core, cygwin64-gcc-core, and djgpp-
> binutils, mingw64-i686-binutils, mingw64-x86_64-binutils, cygwin32-
> binutils, cygwin64-binutils so anyone has the freedom to choose to build
> DOS, Windows, or Cygwin apps targeting their respective APIs, under
> Cygwin, and also have the freedom to give away or sell those apps as long
> as they respect their licences.
> 
> Cygwin's goal is to have everyone and everything believe it is running in
> a POSIX environment and provide interoperability within a Windows
> environment (including Wine) based on POSIX standards, system interfaces,
> toolchains, shells, utilities:
> 
> 	https://pubs.opengroup.org/onlinepubs/9699919799/
> 
> system and network servers and services, plus GUI desktops (GNOME, KDE,
> LXDE, MATE, Plasma, Xfce desktops on X Window System), and apps (task and
> file managers, web browsers, PDF viewers and editors, graphics viewers and
> editors including GIMP). This is all ported and supported by volunteers
> who believe everyone should have a choice, even when for business or
> family reasons they use Windows.

Tnx Brian

I think The Cygwin-community is doing a great job but with some caveats, such as this

We're in need of various posix-libraries and I guess they won't be available if using the mingw-g++/libstdc++ (I guess cygstdc++ is needed then due to some special memory models etc etc etc) ?

I can for sure try it out, but that would be quite cumbersome because the and I guess it'll be a whole lot of hazzle to make it working

I'd rather help out or having a dialog of how to fix std::filesystem, i.e. change the usage of the __CYGWIN__ macro in that implementation, but this seems to be a part of the "real" GCC-distribution o I guess I need to be involved in that open-source-community instead, but I guess it somehow is invoked from this project somehow so I guess some people here do have some real insights about this ?

The whole C/C++ community is striving for total cross-platform libraries (but I guess we have a few years left for that) and std::filesystem was supposed to take us all in that direction and I totally understand that std::filesystem-library in Cygwin do think it is on a posix-filesystem (though it's not) and I totally understand why the behaviour is as it is, but I don't agree that is a good thing, considering that the underlaying posix-implementation already today accepts Windows:ish-like-paths in some circumstances, I'd like the whole package to be even more agnostic because most applications don't have any wish to inspect the content of a path-object no more than the value of a socket-descriptor

Applications might wanna extract type, name, parent-folder, etc but do rarely care about what kind of separator it has (/ or \) and the style of the root directory etc and it would be very neat if the cygwin std::filesystem-library became more agnostic in these regards

Best regards,
Kristian


> --
> Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
> 
> This email may be disturbing to some readers as it contains too much
> technical detail. Reader discretion is advised.
> [Data in binary units and prefixes, physical quantities in SI.]
> --
> Problem reports:      https://cygwin.com/problems.html
> FAQ:                  https://cygwin.com/faq/
> Documentation:        https://cygwin.com/docs.html
> Unsubscribe info:     https://cygwin.com/ml/#unsubscribe-simple

--
Problem reports:      https://cygwin.com/problems.html
FAQ:                  https://cygwin.com/faq/
Documentation:        https://cygwin.com/docs.html
Unsubscribe info:     https://cygwin.com/ml/#unsubscribe-simple

- Raw text -