Re: time to remove Visual Studio project files?
> 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 sources right now so I cannot give exact details.. > I can take a look later next week. If you get a PR put together can you either FU here (or reach out to me directly) and I’ll give it a spin against our somewhat ‘edge’ build? I don’t have the cycles any more to follow the curl github stream directly. Thanks , Rod --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
RE: time to remove Visual Studio project files?
> 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 mismatch between the multiple parameterization options and the configuration types. If you go for a cleanup (or some CMAKE work) I would urge you to consider using the /MP (multi-processor) option. File by file compilation looks very pedestrian these days (although the time taken to do the OpenSSL file-by-file compile pretty much swamps everything). So I guess my answer is "No", "Dunno". Rod --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
RE: smart quotes warning
> 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 enough about character encoding and so forth to know that I don't know anything at all, but my suggestion would be to key any warning on characters whose code is less than 33 or greater than 126. (<=SPC >=DEL). However that may be wildly wrong. ...always assuming that EBCDIC really is a thing of the past which may not be the case... For whatever it's worth R --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
Re: file:// test URLs
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 that you will never get back,,. Sent from my iPad > On 18 Oct 2019, at 23:49, Marcel Raad via curl-library > wrote: > > Hi, > > I'm currently trying to get a successful test suite run for curl compiled > with MSYS GCC, which has more Unix-like behavior compared to MinGW. > (Or, to be exact, I'm trying to be able to add autotools builds to AppVeyor > with only what is preinstalled.) > > Virtually all file:// tests are failing. They use paths like > file://localhost/%PWD%/log/test200.txt > which translates to something like > file://localhost//home/marcel/curl/tests/log/test200.txt > Note the double slash after the host name. This works fine on Linux, but > doesn't on MSYS. > Is this format on purpose? Is it defined to work and an MSYS bug or something > we should fix in the tests? > > Thanks, > Marcel > > > --- > Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library > Etiquette: https://curl.haxx.se/mail/etiquette.html --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
RE: Nmake install prefix
> 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 whether you can just doing by condionalizing the setting of DESTDIR on DESTDIR. Also whether it works from the command line as well as in the environment... If this is a supported variable you need to make a suitable change to MakeFile.vc (alongside WITH_DEVEL and so on). Finally as a general code thing I think I'd prefer !IFDEF WITH_PREFIX DIRDIST = $(WITH_PREFIX) !ELSE DIRDIST = ..\builds\$(CONFIG_NAME_LIB)\ !ENDIF Finally, if you take this to Github can someone mark me a reviewer and I'll try to do a test build? I recently stopped getting all github mails for curl since I was getting swamped... R --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
RE: 7.62.0 brings lots of news, test it early!
> 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 have the cycles to watch the curl process as closely as I'd like. Does pulling from git and building from HEAD equate to the same thing or is there a tag (or a stream of tags) I'd be better to build from? Thanks /R --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
RE: Old Curl Project
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 (as we moved off VC10) but I know that both of those projects build OK with the older tools. I hear where you are coming from (change as little as possible so as to keep the old thing of life-support) but as a curl consumer, I would emphasise Daniels suggestion of going to the latest and greatest (for curl and zlib at least) both these products have (IMO) a good track record of not breaking the ABI and if Daniel says it ain't broken it probably isn’t, it certainly won't be purposely broken. I don't include OpenSSL for want of evidence to the contrary. I'll remark that out move to 1.2 was reasonably complicated but that was because of our need to dive inside OpenSLL's structures for our own needs. FWIW Rod --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
RE: Building on Windows: zlib library names in winbuild/MakeBuild.vc
> 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: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
RE: Building on Windows: zlib library names in winbuild/MakeBuild.vc
> 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, but. A much better PR would be one which allowed the file name to be provided on the nmake line. For instance the standard for windows is for debug DLLs to be called fooD.dll and we do our debug builds like that (allow co-installation of both developments which used to be much more useful than it is there days). Equally, some providers have shown themselves "problematic" in the word of not changing a file name when the change the ABI and we tend to force the issue for them by controlling them. I have an AI since for ever to put such a PR together, and apologise for not doing so. R --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
RE: Minor bugs in curl-7.58.0, plus fixes/changes for Windows builds (fwd)
> 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 some PRs for these as well, but I am not prepared to do any of the manifest stuff - I spend most of my time in kernel mode and I'm not prepared to make security calls based on subtleties I don't have the background to totally grock. R --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
RE: Minor bugs in curl-7.58.0, plus fixes/changes for Windows builds (fwd)
> 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 just get lost at github... /Rod --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
RE: Building curl for older Windows versions
> 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. --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
RE: Re[2]: Static libcurl size under Windows
> 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 but playing around at the edges does seems to indicate that the lib size isn't much bigger than the sum sizes of the objects. HOWEVER the lib link does include the SSL and ZLIB lines explicitly at the start of the command (the old build had them at the end), and that's pretty deeply integrated into the way that the build works. To tease that out one would need to split the CURL_LFLAGS from the LIB_LFLAGS and only add the dependant libs to the CUR_LFLAGS command. Rod --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
RE: Static libcurl size under Windows
> 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 build is using the
linker to create the archive ("you are in a maze of nested symbol indirection,
all alike").
I'll look a bit more this weekend but thusfar I'm coming up dry I'm hoping
someone with stronger nmake-fu than I will dive it.
/Rod
---
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
RE: clang-format, close but no cigar
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 alleged - work on the C compiler) so I'd be worried about letting some random code reformat my code without any external review - particularly if the code came from a project which you seem to indicate is not being maintained. Don't get me wrong I think that automatic style checking is a great help and forcing conformance has got to help, but I'm hoping to hear that you proposing some "checks and balances". /Rod --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
RE: proposed changes for winbuild makefile
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 already know. It’s the leitmotif of every successful Open Source project I have contributed to. You are just more laid back than I am > If you > have a PR you want to submit that will improve winbuild then that's > great, but I doubt anyone can (or should) give you a guarantee that your > work will get in without any friction. I have no problems with that. > We are all reviewed by our peers > and we adjust. Changes may be and often are requested. Or maybe an idea > is a bad or implementation is bad or it just shouldn't be added. I have no problems with that. Once you can get something past the OpenAFS gatekeepers (where no change can be more than about 20 lines difference and each once has to compile as pass tests) you can get anything committed. But I'm struggling to work out the protocol for this project. For instance: > Concerning the patch I did not review it however what was ultimately > proposed in 1201 [1] I think seems to make a lot of sense. Whilst I agree that it seems to make sense, I'm not sure if I'm embarrassed or saddened that this PR wasn't on my horizon after several weeks of discussion. Should I have been communicating there? I am very new to this project and I may have missed on protocol - advice would be welcomed: despite my cynicism I am willing to contribute to help the common good. > We need support for OpenSSL 1.1.0 libraries, and so I think the ability > to override the variables on the command line seems like a good idea. I believe so, but it comes at the cost of downstream support. Once you "document" something it has to work forever - that’s why I like these changes, I can move our build over to a supported mechanism. > Changing the static library to roll up all the dependencies in one big > library I think is a bad idea. It makes me itch and I would build both dll and lib from the same objs; but I'm not a usermode library specialist = the DLLs I usually author are kernel-mode drivers. In this case I'd follow the reviewers as to what to do (and in doing so I must mention that I understand that I forgo my right to whine after the event). So, what's needed? Do we (Kees and I) need to deconstruct the patch? Shall I start from scratch and do what I need and work with Kees to make it do what it should? Thanks again Rod --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
RE: proposed changes for winbuild makefile
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 resources. FWIW Our current build methodology involves editing the makefiles, unless we can get closure in here I'll just carry on doing that. AFAICS Daniel, quite rightly, won't pick up a patch unless he hears assent, I'm hearing nothing. To summarise: The proposal is to move several internal parameterizations to do with the names and sources of various LIBS onto the command line and document them - making their use "supported" in some way. This will be backwards compatible with this particular flavour of building on windows I might even be able to help Kees turn his patch (which current reads as a replacement) into a string of patches in a PR. However I'm not going to spend a second further on this problem unless I get a strong feeling that anyone else cares and (more importantly) that, once I have wasted all that time, they won't start caring enough to throw up roadblocks. Rod --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
RE: proposed changes for winbuild makefile
> 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 fix/patch get applied. I'm not very loud on this list either, but Daniel asked someone to jump in, so I did. I'm hoping that all the lurking Windows users out there and/or Daniel will eventually chime in. I can't provide more of a steer, but it seems like "a compelling case" is a good way to get a patch committed. But as Daniel said elsewhere recently, the silence is deafening. If we add the BASE_NAME stuff, the changes you propose would work well for me and I cannot see that it would break any existing user - if you believe my line that "what's in the help text will be backwards compatible, nothing else is guaranteed. /Rod --- List admin: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
RE: proposed changes for winbuild makefile
> 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 MAKE="NMAKE /E" hack which then allows me to override the internal workings of MakefileBuild.vc. If I was the one supporting this build system I would say that that puts me outwith "supported usage" - the more so since the parameterisation I then use isn't listed when I say "nmake /f Makefile.vc". As a builder and deployer this makes me nervous and I need to check that the makefiles haven't changed between releases. In order for this build to add any value for me I'd need to be able to set BASE_NAME and BASE_NAME_DEBUG (patch attached). I need to do this to proactively avoid DLL hell further down the line. It would also make me more comfortable to know that I was using supported options (by adding them to the help text). The ones I use which are not in the help text are ZLIB_LFLAGS BASE_NAME BASE_NAME_DEBUG ZLIB_CFLAGS ZLIB_LIBS SSL_LIBS Your example uses the last three, plus LIBPATH, SSH2_LIBS, SSH2_CFLAGS, so at least those should be added to the help text. It occurs to me as I type this that you can also finesse the huge path issue by just allowing a used to short cut in the setting of CONFIG_NAME_LIB in Makefile.vc. Hope this helps Rod 0002-Modify-Kees-s-patch-to-allow-command-line-override-o.patch Description: Binary data --- List admin: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
RE: proposed changes for winbuild makefile
> 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 get significant push back if you changed it. We need something _like_ that because we build 4 versions (x86,x64) x (Debug, Release) in series for all our dependencies so we cannot have them all going to the same place. OpenSSL does this and the way we handle that is to build all the way to sw_install and then "install" to the directories called (Win32, Win32Debug, x64, x64Debug). As an aside we can then just pop that into WITH_DEVEL when building curl. However for the four types, we always build the same sub-flavour (zlib-dll, ssh-dll, mode=dll, winssl=no) . /Rod --- List admin: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
RE: proposed changes for winbuild makefile
> 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 ... And thereby hangs the rub for all of use trying to build on Windows. Nonetheless "The best is the enemy of the good". We'd all like to start again from scratch and that isn't going to happen (and if I did I would spend my time making the VCXProj stuff work for me - although I'm hearing enough terrifying things about VC17 to not even entertain going there) I'm still working through your patch and should have some comments this week. I'll try to separate the "must changes" from the "it would be great if" changes from the "well if you were starting from scratch you could do it like this. Given what I say above: so long I can bludgeon what you are proposing hard enough to build the artifacts I need with the names I need there won't be any "must changes". R --- List admin: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
RE: Removing */Makefile.vc[num] !
I think that you also want to remove winbuild\Makefile.msvc.names A quick grep through the sources appears to indicate that (despite it's location) the only *make* files to include it are the Makefile.vc[num] ones. > -Original Message- > From: curl-library [mailto:curl-library-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 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. > > Every lite bit counts, so yes it does! > > > For me, silence should be considered as an assert (or at least as a > > revocation of whining-rights :-). > > Absolutely. > > Though history proves that a lot of our users (even very large libcurl users) > don't read this mailing list much and don't keep up with our daily struggles, > so they'll come running much later once we've shipped the changes in a public > release... > > -- > > / daniel.haxx.se > --- > List admin: https://cool.haxx.se/list/listinfo/curl-library > Etiquette: https://curl.haxx.se/mail/etiquette.html --- List admin: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
RE: proposed changes for winbuild makefile
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 solve some things to be able to build curl with zlib, libssh2 and > openSSL libraries at a different location, and with different > names. That’s one example of what we need. > - The openSSL libraries have been renamed as of openSSL 1.1.0x. As is that. > An example of calling the make is: nmake -f Makefile.vc mode=static VC=14 > WITH_SSL=static WITH_ZLIB=static WITH_SSH2=static > GEN_PDB=yes DEBUG=no MACHINE=x64 SSL_CFLAGS="/I$(OpenSSLIncDir)" > ZLIB_CFLAGS="/I$(ZlibIncDir)" > SSH2_CFLAGS="/I$(Libssh2IncDir)" SSL_LIBS="libcrypto.lib libssl.lib" > ZLIB_LIBS=zlib.lib SSH2_LIBS=libssh2.lib > DEVEL_LFLAGS="/LIBPATH:$(OpenSSLLibDir) /LIBPATH:$(ZlibLibDir) > /LIBPATH:$(Libssh2LibDir)". The $(xxx) are variables that point to > the actual include and library paths. That looks about what we'd need. I'm assuming that somewhere in there is an inferred "ENABLE_WINSSL=no" Is there the option of setting BASE_NAME and BASE_NAME_DEBUG? we need that (to keep the dll name space separate). > - There was no clean target in Makefile.vc. And the clean target in > MakefileBuild.vc was unreachable, due to some tests. This has > been fixed, and nmake -f Makefile.vc mode=static clean now works. Great news!. Thanks. > - Minor cleanup in MakefileBuild.vc: DEVEL_BIN was not used. > This is my first contribution to this mailing list. Not sure whether all > information is provided. The patch is in *NIX style format and can > be applied by using the patch tool. Hmm. Let's see whether git can eat it, failing that I guess that the Unix support in "Anniversary Edition" will eat it. I'll try and review this this week. Rod --- List admin: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
RE: Removing */Makefile.vc[num] !
> 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 whining-rights :-). R --- List admin: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
RE: [SECURITY ADVISORY] curl invalid URL parsing with '#'
> 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 many decades) in working with issues in other packages and their assumption (or otherwise) about current working directory and what relative and absolute paths look like. This is always going to be a delicate area. I always end up getting something which works in an explainable way, but it's never what I thought would work first time. My observation was made more in support of your inferred conclusion that that any breakage as a result of this fix is explainable and no less broken than before. Thanks, and sorry for the noise. Rod --- List admin: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
RE: [SECURITY ADVISORY] curl invalid URL parsing with '#'
> 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 work, go try it on Windows where the "Dos Device Name" makes a mess with a lot of assumptions that all absolute paths start with a '/'. Also not every OS or runtime environment supports the assumption of "current working directory". /Rod --- List admin: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
RE: obsoleting ONE of the windows build systems
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 working, I needed to use a bit of a blunt tool and so I wanted to share it here in case you want to change things (in which case I'll offer help so long as I can change a couple of other things we would like!) To recap, the core issue is that in OpenSSL >= 1.1 the lib names are LIBSSL.LIB and LIBCRYPTO.LIB. Up to now they had been LIBEAY32.LIB and SSLEAY32.LIB. Most build systems (including this one) "just know" what the lib names are and so this is a bit of a curve-ball. To make the new build work for OpenSSL I needed a command pretty much like this: nmake /f Makefile.vc mode=dll WITH_DEVEL=H:\MyBuild\x86 WITH_SSL=dll WITH_ZLIB=dll ENABLE_WINSSL=no VC=10 DEBUG=no MAKE="NMAKE /e" SSL_LIBS="libssl.lib libcrypto.lib" The critical bits are the last two: The line MAKE="NMAKE /e" tells MakefileBuild.vc to listen to the setting of SSL_LIBS on the command line and not to its own calculations which are based on the setting of WITH_SSL. With this in place we build just fine. This is sufficient for us because we need to commit similar abuse in order to set the ZLIB libraries and paths. This is because we use VS Paradigm for location of files in Windows [Shibboleth/x64/Debug] and we also demand tighter control on DLL names because of ABI drift. This is just a choice, there is no right or wrong and I'm not into religious arguments about build technologies, but it makes for a cumbersome marriage with this build system unless I hardwire the macros and do the "NMAKE /E" thing. If however you want to add the smarts to MakefileBuild.vc to handle different lib names I'd be wanted to expose similar tools to allow us to set similar macros on the command line. Thanks Rod --- List admin: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
RE: obsoleting ONE of the windows build systems
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 nmake process, but you'd listen to any eventual issues we found if we plumped for the vcxproj route.. I'll move forward base on this assumption and evaluate our options. Of course if I can make reasonable proposal for changes to whichever mechanism we end up using I'll post them as PRs. Thanks all. /Rod --- List admin: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
RE: obsoleting ONE of the windows build systems
+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... It also seems to be the way the Microsoft wants us to move /Rod --- List admin: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
RE: libcurl - windows / unicode filenames support...
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 hang out). Is there a case I can look out or is google my friend? R --- List admin: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
