I have a PR that asks the linker (via the compiler) what its implicit
search directories are instead.
It is the right way to do it IMHO, but I need to find time to finish it
unfortunately.
On Feb 6, 2017 11:16 PM, "Jörg Krause" wrote:
> On Mon, 2017-02-06 at 22:22 +0100, Jörg Krause wrote:
> >
; Am 2017-02-07 02:46, schrieb Ray Donnelly:
>>
>> I have a PR that asks the linker (via the compiler) what its implicit
>> search directories are instead.
>>
>> It is the right way to do it IMHO, but I need to find time to finish
>> it unfortunately.
>
>
>
On Mon, Feb 27, 2017 at 8:50 PM, Jörg Krause
wrote:
> Hi Brad,
>
> On Mon, 2017-02-27 at 11:43 -0500, Brad King wrote:
>> On 02/07/2017 04:40 AM, Ray Donnelly wrote:
>> > > > I have a PR that asks the linker (via the compiler) what its
>> > > > imp
On Mon, Feb 27, 2017 at 9:39 PM, Brad King wrote:
> On 02/27/2017 03:54 PM, Ray Donnelly wrote:
>> This is why my PR asks the linker that the compiler will use for the
>> actual list of implicit link dirs. I'm sorry I've not had time to
>> write up a clear explana
Our why doesn't cmake set a long needed standard here of .dll.lib and be
done with this nonsense?
On Thu, Mar 22, 2018, 11:58 PM P F via CMake wrote:
> Why not install shared libraries in one location and static libraries in
> another?
>
> > On Mar 21, 2018, at 4:55 AM, Mario Emmenlauer
> wrote
And the situation is *far* worse on Windows where the extension for a dll
import library is the same as for a static library because cmake refuses to
try to move the needle on this awful 'defacto' decision with respect to
msvc when it is exactly the sort of thing cmake should strive to take the
lea
On Sat, May 19, 2018, 8:50 PM Mateusz Loskot wrote:
> On 19 May 2018 at 15:00, Elvis Stansvik
> wrote:
> > I know this has been asked before, but I've never seen a really
> > authoritative answer.
> >
> > Say I have a simple single-library project.
> >
> > The advise I've seen is to not pass SHA
istinction, at least.
>
>
>
> *From: *CMake on behalf of Ray Donnelly <
> mingw.andr...@gmail.com>
> *Date: *Saturday, May 19, 2018 at 6:10 AM
> *To: *Elvis Stansvik
> *Cc: *CMake MailingList
> *Subject: *Re: [CMake] Approach to both shared and static lib (again,
> so
On Sat, May 19, 2018, 9:38 PM Mateusz Loskot wrote:
> On 19 May 2018 at 22:16, Ray Donnelly wrote:
> > On Sat, May 19, 2018, 8:50 PM Mateusz Loskot wrote:
> >> On 19 May 2018 at 15:00, Elvis Stansvik
> wrote:
> >> > I know this has been asked bef
On Sat, May 19, 2018 at 11:55 PM, Elvis Stansvik
wrote:
> 2018-05-19 21:49 GMT+02:00 Mateusz Loskot :
>> On 19 May 2018 at 15:00, Elvis Stansvik wrote:
>>> I know this has been asked before, but I've never seen a really
>>> authoritative answer.
>>>
>>> Say I have a simple single-library project.
ing will work
> fine. And it looks that is not even necessary on Linux, because the
> RPATH is already set by the toolchain.
>
> El lun., 13 de ago. de 2018 a la(s) 13:35, Isaiah Norton
> (isaiah.nor...@gmail.com) escribió:
>>
>> See also:
>>
>> https://git
Docker is unnecessary overhead here and irrelevant to the question of which
compilers to use when building conda packages (use ours or risk binary
incompatibility with the rest of the ecosystems, please do not attempt to
use e.g. CentOS6 system compilers to compile modern software either!). Docker
Hi Sebastián,
Without having time to properly go through this, I feel I should
correct some technical inaccuracies, but *all* of your issues can be
sidestepped by using conda-build. Installation and RPATHs are always
very tricky for projects to get right so we side step any issues here
by running
Our compiler activation scripts (highlighting the bit of most interest
to you I hope) are here:
https://github.com/AnacondaRecipes/aggregate/blob/master/ctng-compilers-activation-feedstock/recipe/activate-gcc.sh#L84-L101
On Wed, Aug 15, 2018 at 11:44 AM, Ray Donnelly wrote:
> Hi Sebast
On Wed, Aug 15, 2018, 3:05 PM Sebastián Mancilla wrote:
> My 5c: Docker is just too annoying to work with if you are targeting users
> to run your packages.
>
> From the point of view of the final user of your "binary distribution"
> (some Docker image):
>
> - You have to figure out / copy paste
Hi Dmitry,
You should report this on MSYS2's github repo (Alexpux), we apply some
patches to Qt's CMake files and one of those may have caused this
issue. It's unlikely to be a problem with CMake.
On Thu, Oct 4, 2018 at 12:14 PM Dmitry Mikushin
wrote:
>
> Dear all,
>
> I'm currently looking into
> which I bet all of us would love to see.
This is not correct. I would strongly prefer they continue with QBS
instead. Cmake is defacto, but very suboptional.
On Tue, Nov 27, 2018, 10:28 AM Rolf Eike Beer Am 2018-11-09 10:04, schrieb Torsten Robitzki:
> > Hi,
> > I hope this question was not as
Cmake is already full of do much hardcoded logic / flags and does new
releases so frequently (maybe there's some correlation between these two)
that adding this would hardly impact upon its quality or maintainability.
So to that end, hardcoding the default per msvc version so that it's not
added u
The problem is the time required to upstream such work. Unfortunately I do
not have that time.
On Tue, Jun 25, 2019, 12:15 AM Alan W. Irwin
wrote:
> On 2019-06-24 07:39-0600 Christopher Webster wrote:
>
> > Thank you Benjamin, that [install and use mingw-w64-x86_64-cmake in the
> mingw64 shell]
lly tried to use a Digia-provided (I think) Qt
static build for something work-related about a year ago, and because
it requires a specific version of the msvc++ runtime I don't think it
fits any useful definition of 'static'. Qt static built with MinGW-w64
does though as
On Sat, Feb 21, 2015 at 9:59 AM, Stephen Kelly wrote:
> Ray Donnelly wrote:
>
>>> >
>>> > 1) Am I right when I say CMake, Qt and static linking don’t mix ?
>>>
>>> They should mix fine.
>
> What I meant when I wrote this was 'they sho
ertain, so
I'd like to make a change to how CMake itself behaves somehow. If you
can guide me on an acceptable way to achieve this I'd like to try to
come up with a patch.
--
Best regards,
Ray Donnelly.
--
Powered by www.kitware.com
Please keep messages on-topic and check the C
On Mon, Dec 14, 2015 at 2:42 AM, Alan W. Irwin
wrote:
> On 2015-12-14 01:06-0000 Ray Donnelly wrote:
>
>> Hi,
>>
>> I ran into a problem on MSYS2 recently building llvm+clang for
>> mingw-w64 using CMake 3.4.1 (we carry a few local patches, they're
>> fai
On Mon, Dec 14, 2015 at 12:43 PM, Ray Donnelly wrote:
> On Mon, Dec 14, 2015 at 2:42 AM, Alan W. Irwin
> wrote:
>> On 2015-12-14 01:06- Ray Donnelly wrote:
>>
>>> Hi,
>>>
>>> I ran into a problem on MSYS2 recently building llvm+clang for
>>
On Mon, Dec 14, 2015 at 8:02 PM, Alan W. Irwin
wrote:
> On 2015-12-14 12:43-0000 Ray Donnelly wrote:
>
>> The issue I've got here is that on MSYS2 we've decided that we don't
>> want to provide libdl for mingw-w64 but do provide it for msys2, so
>> there
25 matches
Mail list logo
