> On 5 Sep 2020, at 17:13, Joel Winarske via curl-library
> wrote:
>
> I would say if the two were brought to parity then you could drop the nmake
> files.
That’s a pretty big if. There are a lot of things at the edge of the NMAKE
build which might be problematic. I’m away from my
> Do you use them? Why isn't generating these files using cmake good enough?
I appreciate that this doesn't fully answer your question but
I'd be *very* reluctant to see the NMAKE files go, but we have never used the
vcxproj files. As I recall, I couldn't get over the apparent impedance
> I polled a couple of colleagues and they had also been bitten by this issue
> in the past.
Not personally but I make limited use of the command line. However, a constant
issue with our customer base is cut and paste (normally of XML) not working
because of this sort of nonsense.
I know
I’m sure we went through this about a year ago. As I recall a bad
implementation many many years ago got people trained to do the wrong thing and
doing the right thing breaks too much, but others will remember.
Don’t go there, from personal experience it will take up huge chunks of your
life
> Any Windows developer who would object?
Not from here. Looks pretty benign.
Some side notes:
I can never remember under what circumstances NMAKE inherits environmental
variable (with and withour /e) so I cannot work out whether this wouldn't
either need some work in Makefile.vc and/or
> This is just a small request and reminder that if you can, we will appreciate
> if you get and try out a recent daily snapshot of curl in your application or
> environment as an extra precaution to verify that we haven't broken anything
> significantly!
Sorry for the stupid question, I don't
Don,
> A preliminary test showed that the basic Curl-7.20 version builds
> successfully on XP, however it would seem that this build is void of the
> required libraries: openssl, c-ares or zlib.
Speaking for OpenSSL and Zlib - you have to build these yourself. We recently
retired our XP build
> But unless that's imminent,
Don't hold your breath for anything from me. Sorry
> it would be great (for me at least!) to
> get this smaller PR in so I don't need to maintain it separately.
+1
---
Unsubscribe:
> If it's nothing, then I'm happy to provide a PR that either:
>1, Uses the library names that zlib documents, or
>2, Supports both existing names and the documented zlib names by
> checking for existence of files in DEVEL_LIB similar to the checks for
> OpenSSL.
This would be great,
> Yes, there's a lot of value in that! Issues don't get lost as easily on github
> as in our well trafficed mail boxes. Ideally they can even be submitted as
> proper pull-requests as then we can merge them once we agree they're fine.
OK, I'll take am AI to pop in cases. I may take a shot at
> I fell over this email that I received from Stefan Kanthak a while ago but
> forgot about. A list of flaws/fixes he suggests we do.
Daniel,
I am not so "up" on your process (I lurk mostly), but is there any value in
putting these into github? Then they'll not get lost in a mailbox. They'll
> So, my question is this: When building with nmake as per the docs, how should
> we specify the Windows target version?
To go in another direction - does it depend on the nmake version? I managed
to jettison XP last summer but up to that point I'd built my stack against
VC2010.
> Maybe it's worth trying to build VB with that huge libcurl and see what
> happens... But I wanted to check out what's happenning with libcurl first.
If it's not too daunting a task I'd be tempted to do that.
I'm hindered in that I don't build statically at all so my environment isn't
set up
> Does anyone know why we're rolling all dependencies into static libcurl lib?
I looked and timed out. I don't speak nmake too good but thus far it looks
like an artefact of the way the dll is built "Put in appropriate references for
everything". Also I cannot get over this suspicion that the
I'd like to understand how you'd envisage using it. Do you mean a one-time
convert of the code (with appropriate review of course)? Or require that a
module be acceptable before it gets checked in? Or some combination?
I'm a Luddite (and I'm old enough to remember Ken Thompson's - possibly
Ray,
Thanks for taking the time to respond.
TLDR; Some people are listening, tell me what to do next.
> . I wouldn't expect to hear anything from 99% of them
> unless it stops working, because that's usually the way it goes
I deleted my response to that - it didn't say anything you won't
Surely someone other than Kees and I actually deploy on Windows? I find it
extraordinarily frustrating when Daniel or I or Kees put in a proposal and all
we hear is emptiness.
I'm happy to review and test work done by anybody who wants to help, but I
cannot waste my project's minimal
> Is this a question to me to provide information to the help text?
It’s a suggestion to you to do so. With the hope that if someone out there
thinks it a bad idea they'll chime in.
> (Note that this is the first time I was involved in this mailing list, I don't
> know the procedure how a
> I'm still working through your patch and should have some comments this week.
>
I've now used the applied patch (had to be done in a unix world) to build and
deploy cUrl and our downstream dlls.
So this patch isn't a show stopper for us.
On the other hand I still have to use the
> I don't know whether there is a practical use of building each flavor in its
> own output directory. Please let me know if you want such. I
> still find this makefile (too) complex.
It’s the way Curl the builds currently work and the way the previous generation
worked so I suspect that you'd
> This is because the name of the target depends at runtime
> whether a DLL or static curl library is built.
Can this not be hidden inside Makefile.vc?
!if "$(mode)"=="dll"
TARGET=dll_bla_bla
!else
TARGET=static_bla_bla_bla
!fining
> I don’t have time now to fix this all, but normally ...
y-boun...@cool.haxx.se] On Behalf Of
> Daniel Stenberg
> Sent: 17 January 2017 10:53
> To: libcurl development
> Subject: RE: Removing */Makefile.vc[num] !
>
> On Tue, 17 Jan 2017, Rod Widdowson wrote:
>
> >> In spite of the ear-numbing silence on this topic, I've pu
I'd need to see how we would build with this (we build mostly WITH_xxx=dll),
but a priori it addresses many of the problems that we
are currently addressing the MAKE="NMAKE /e" trick...
https://git.shibboleth.net/view/?p=cpp-msbuild.git;a=blob;f=dependencies/libcurl-new.bat;hb=HEAD
> I had to
> In spite of the ear-numbing silence on this topic, I've pushed a
> pull-request[1] and made a branch[2] available for testing. All and any
We've moved off it. In case that helps bolster your case. For me, silence
should be considered as an assert (or at least as a revocation of
> Are you suggesting curl's current handling of file:// doesn't work properly on
> Windows?
Not in the slightest (and if I had something found you'd have heard about it).
I've honestly not had the opportunity to look. I just know that I have spent
more cycles than I would want (going back
> First: I don't think it is clear in any spec that local file:// URLs actually
> work.
[Good stuff snipped]
> file:// didn't work very good for relaive file paths before this commit
[More Good stuff snipped]
A word from the peanut gallery: as soon as you think that you understand how
this
To kick this one back into the park again...
I managed to make the new (Windows) build system work for us, and in particular
to make it work for OpenSSL1.1. Thanks for the prod.
I have made a few minor changes to the winbuild system as
https://github.com/curl/curl/pull/955
To get OpenSSL1.1
So, to summarise what I'm hearing:
The msbuild/nmake system is 'the' way to do builds, and the vcxproj is aimed at
getting people bootstrapped into the project. So if
I was looking at our very much batch-build (2 architectures x 2 profiles)
oriented process up I should start by looking at the
+1 from me (as the source of the problem).
What's the story with the projects\vcXXX tree. I think that it is less capable
than the command line, but we are trying to move our projects that way with,
"msbuild foo.sln /p:Debug|Release /platform=x64" being left available to
command line users...
Aside, but curious minds need to know.
As a newcomer here - can someone help me what "Unicode for windows" means? I
have to assume it is in URL handling, not files? The word UTF8 has to be the
give-away since UTF8 is a pretty alien concept for windows at the k-mode
interface (where I mostly
30 matches
Mail list logo
