moparisthebest/curl
1
0
Fork 0
mirror of https://github.com/moparisthebest/curl synced 2024-11-16 14:35:03 -05:00
Code Issues Releases Wiki Activity
1cafede9f2
curl/tests/libtest/Makefile.inc

434 lines
14 KiB
PHP
Raw Normal View History

Added missing tests in CMake, added Makefile.inc for tests (+ use in CMake scripts), and fixed a missing define under windows in a test source file.
2009-04-07 17:59:15 -04:00
# files used only in some libcurl test programs
TESTUTIL = testutil.c testutil.h
tests: enable time tracing on tests 500, 573 and 585
2012-01-17 15:33:17 -05:00
# files used only in some libcurl test programs
TSTTRACE = testtrace.c testtrace.h
compiler warning: fix Fix compiler warning: variable was set but never used Fix compiler warning: clobber ignored
2011-05-26 06:40:04 -04:00
# files used only in some libcurl test programs
Makefile.inc: fix $(top_srcdir) not allowed in _SOURCES variables
2013-01-19 22:17:11 -05:00
WARNLESS = ../../lib/warnless.c ../../lib/warnless.h
compiler warning: fix Fix compiler warning: variable was set but never used Fix compiler warning: clobber ignored
2011-05-26 06:40:04 -04:00
Added missing tests in CMake, added Makefile.inc for tests (+ use in CMake scripts), and fixed a missing define under windows in a test source file.
2009-04-07 17:59:15 -04:00
# these files are used in every single test program below
SUPPORTFILES = first.c test.h
# These are all libcurl test programs
tests: add #96 #558 and #1330 These verfy that the 'memory tracking' subsystem is actually doing its job when using curl tool (#96), a test in libtest (#558) and also a unit test (#1330), in order to prevent regressions in this functionallity.
2013-03-15 14:58:00 -04:00
noinst_PROGRAMS = chkhostname libauthretry libntlmconnect \
lib500 lib501 lib502 lib503 lib504 lib505 lib506 lib507 lib508 lib509 \
lib510 lib511 lib512 lib513 lib514 lib515 lib516 lib517 lib518 lib519 \
lib520 lib521 lib523 lib524 lib525 lib526 lib527 lib529 lib530 lib532 \
lib533 lib536 lib537 lib539 lib540 lib541 lib542 lib543 lib544 lib545 \
lib547 lib548 lib549 lib552 lib553 lib554 lib555 lib556 lib557 lib558 \
test559: verify use of minimum CURLOPT_BUFFERSIZE
2017-05-04 09:39:04 -04:00
lib559 lib560 lib562 lib564 lib565 lib566 lib567 lib568 lib569 lib570 \
tests: add #96 #558 and #1330 These verfy that the 'memory tracking' subsystem is actually doing its job when using curl tool (#96), a test in libtest (#558) and also a unit test (#1330), in order to prevent regressions in this functionallity.
2013-03-15 14:58:00 -04:00
lib571 lib572 lib573 lib574 lib575 lib576 lib578 lib579 lib582 \
lib583 lib585 lib586 lib587 lib590 lib591 lib597 lib598 lib599 \
lib1500 lib1501 lib1502 lib1503 lib1504 lib1505 lib1506 lib1507 lib1508 \
tests: added test1517 ... for checking ability to receive full HTTP response when POST request is used with slow read callback function. This test checks for bug #657 and verifies the work-around from 72d5e144fbc6. Closes #720
2016-03-17 13:04:20 -04:00
lib1509 lib1510 lib1511 lib1512 lib1513 lib1514 lib1515 lib1517 \
tests: Added test for bug #1456
2014-12-28 07:12:09 -05:00
lib1520 \
easy: Initialize info variables on easy init and duphandle - Call Curl_initinfo on init and duphandle. Prior to this change the statistical and informational variables were simply zeroed by calloc on easy init and duphandle. While zero is the correct default value for almost all info variables, there is one where it isn't (filetime initializes to -1). Bug: https://github.com/curl/curl/issues/1103 Reported-by: Neal Poole
2016-11-05 23:05:52 -04:00
lib1525 lib1526 lib1527 lib1528 lib1529 lib1530 lib1531 lib1532 lib1533 \
tests: Add some testcases for recent new features. Add missing tests for CURLINFO_SCHEME, CURLINFO_PROTOCOL, %{scheme}, and %{http_version} closes #1143
2016-11-25 16:32:32 -05:00
lib1534 lib1535 lib1536 \
include: curl/system.h is a run-time version of curlbuild.h system.h is aimed to replace curlbuild.h at a later point in time when we feel confident system.h works sufficiently well. curl/system.h is currently used in parallel with curl/curlbuild.h curl/system.h determines a data sizes, data types and include file status based on available preprocessor defines instead of getting generated at build-time. This, in order to avoid relying on a build-time generated file that makes it complicated to do 32 and 64 bit bields from the same installed set of headers. Test 1541 verifies that system.h comes to the same conclusion that curlbuild.h offers. Closes #1373
2017-03-29 08:38:56 -04:00
lib1540 lib1541 \
tests: add #96 #558 and #1330 These verfy that the 'memory tracking' subsystem is actually doing its job when using curl tool (#96), a test in libtest (#558) and also a unit test (#1330), in order to prevent regressions in this functionallity.
2013-03-15 14:58:00 -04:00
lib1900 \
lib2033
NTLM tests: boost coverage by forcing the hostname A shared library tests/libtest/.libs/lihostname.so is preloaded in NTLM test-cases to override the system implementation of gethostname(). It makes it possible to test the NTLM authentication for exact match, and this way test the implementation of MD4 and DES. If LD_PRELOAD doesn't work, a debug build willl also workk as debug builds are now made to prefer a specific environment variable and will then return that content as host name instead of the actual one. Kamil wrote the bulk of this, Daniel Stenberg polished it.
2010-07-29 18:47:49 -04:00
Makefile.inc: fix $(top_srcdir) not allowed in _SOURCES variables
2013-01-19 22:17:11 -05:00
chkhostname_SOURCES = chkhostname.c ../../lib/curl_gethostname.c
build: libhostname and chkhostname linkage adjustments followup
2010-08-08 23:45:11 -04:00
chkhostname_LDADD = @CURL_NETWORK_LIBS@
build: chkhostname build adjustments followup
2010-08-07 11:39:36 -04:00
chkhostname_DEPENDENCIES =
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
chkhostname_CPPFLAGS = $(AM_CPPFLAGS)
Added missing tests in CMake, added Makefile.inc for tests (+ use in CMake scripts), and fixed a missing define under windows in a test source file.
2009-04-07 17:59:15 -04:00
tests/libtest/Makefile.inc: sort build targets
2013-01-15 10:04:31 -05:00
libntlmconnect_SOURCES = libntlmconnect.c $(SUPPORTFILES) $(TESTUTIL) $(WARNLESS)
libntlmconnect_LDADD = $(TESTUTIL_LIBS)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
libntlmconnect_CPPFLAGS = $(AM_CPPFLAGS)
tests/libtest/Makefile.inc: sort build targets
2013-01-15 10:04:31 -05:00
libauthretry_SOURCES = libauthretry.c $(SUPPORTFILES)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
libauthretry_CPPFLAGS = $(AM_CPPFLAGS)
tests/libtest/Makefile.inc: sort build targets
2013-01-15 10:04:31 -05:00
tests: enable time tracing on tests 500, 573 and 585
2012-01-17 15:33:17 -05:00
lib500_SOURCES = lib500.c $(SUPPORTFILES) $(TESTUTIL) $(TSTTRACE)
build: prevent global LIBS from influencing libtest build targets
2012-11-30 08:34:48 -05:00
lib500_LDADD = $(TESTUTIL_LIBS)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
lib500_CPPFLAGS = $(AM_CPPFLAGS)
Added missing tests in CMake, added Makefile.inc for tests (+ use in CMake scripts), and fixed a missing define under windows in a test source file.
2009-04-07 17:59:15 -04:00
lib501_SOURCES = lib501.c $(SUPPORTFILES)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
lib501_CPPFLAGS = $(AM_CPPFLAGS)
Added missing tests in CMake, added Makefile.inc for tests (+ use in CMake scripts), and fixed a missing define under windows in a test source file.
2009-04-07 17:59:15 -04:00
test suite: libtest header inclusion cleanup - follow-up Adjust tests/libtest/Makefile.inc and remove a couple of unused headers from tests/libtest/lib583.c
2011-09-06 12:11:11 -04:00
lib502_SOURCES = lib502.c $(SUPPORTFILES) $(TESTUTIL) $(WARNLESS)
build: prevent global LIBS from influencing libtest build targets
2012-11-30 08:34:48 -05:00
lib502_LDADD = $(TESTUTIL_LIBS)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
lib502_CPPFLAGS = $(AM_CPPFLAGS)
Added missing tests in CMake, added Makefile.inc for tests (+ use in CMake scripts), and fixed a missing define under windows in a test source file.
2009-04-07 17:59:15 -04:00
compiler warning: fix Fix compiler warning: variable was set but never used Fix compiler warning: clobber ignored
2011-05-26 06:40:04 -04:00
lib503_SOURCES = lib503.c $(SUPPORTFILES) $(TESTUTIL) $(WARNLESS)
build: prevent global LIBS from influencing libtest build targets
2012-11-30 08:34:48 -05:00
lib503_LDADD = $(TESTUTIL_LIBS)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
lib503_CPPFLAGS = $(AM_CPPFLAGS)
Added missing tests in CMake, added Makefile.inc for tests (+ use in CMake scripts), and fixed a missing define under windows in a test source file.
2009-04-07 17:59:15 -04:00
compiler warning: fix Fix compiler warning: variable was set but never used Fix compiler warning: clobber ignored
2011-05-26 06:40:04 -04:00
lib504_SOURCES = lib504.c $(SUPPORTFILES) $(TESTUTIL) $(WARNLESS)
build: prevent global LIBS from influencing libtest build targets
2012-11-30 08:34:48 -05:00
lib504_LDADD = $(TESTUTIL_LIBS)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
lib504_CPPFLAGS = $(AM_CPPFLAGS)
Added missing tests in CMake, added Makefile.inc for tests (+ use in CMake scripts), and fixed a missing define under windows in a test source file.
2009-04-07 17:59:15 -04:00
lib505_SOURCES = lib505.c $(SUPPORTFILES)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
lib505_CPPFLAGS = $(AM_CPPFLAGS)
Added missing tests in CMake, added Makefile.inc for tests (+ use in CMake scripts), and fixed a missing define under windows in a test source file.
2009-04-07 17:59:15 -04:00
lib506_SOURCES = lib506.c $(SUPPORTFILES)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
lib506_CPPFLAGS = $(AM_CPPFLAGS)
Added missing tests in CMake, added Makefile.inc for tests (+ use in CMake scripts), and fixed a missing define under windows in a test source file.
2009-04-07 17:59:15 -04:00
compiler warning: fix Fix compiler warning: variable was set but never used Fix compiler warning: clobber ignored
2011-05-26 06:40:04 -04:00
lib507_SOURCES = lib507.c $(SUPPORTFILES) $(TESTUTIL) $(WARNLESS)
build: prevent global LIBS from influencing libtest build targets
2012-11-30 08:34:48 -05:00
lib507_LDADD = $(TESTUTIL_LIBS)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
lib507_CPPFLAGS = $(AM_CPPFLAGS)
Added missing tests in CMake, added Makefile.inc for tests (+ use in CMake scripts), and fixed a missing define under windows in a test source file.
2009-04-07 17:59:15 -04:00
lib508_SOURCES = lib508.c $(SUPPORTFILES)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
lib508_CPPFLAGS = $(AM_CPPFLAGS)
Added missing tests in CMake, added Makefile.inc for tests (+ use in CMake scripts), and fixed a missing define under windows in a test source file.
2009-04-07 17:59:15 -04:00
test509: libcurl initialization with memory callbacks and actual usage
2013-03-13 16:49:50 -04:00
lib509_SOURCES = lib509.c $(SUPPORTFILES)
lib509_CPPFLAGS = $(AM_CPPFLAGS)
Added missing tests in CMake, added Makefile.inc for tests (+ use in CMake scripts), and fixed a missing define under windows in a test source file.
2009-04-07 17:59:15 -04:00
lib510_SOURCES = lib510.c $(SUPPORTFILES)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
lib510_CPPFLAGS = $(AM_CPPFLAGS)
Added missing tests in CMake, added Makefile.inc for tests (+ use in CMake scripts), and fixed a missing define under windows in a test source file.
2009-04-07 17:59:15 -04:00
lib511_SOURCES = lib511.c $(SUPPORTFILES)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
lib511_CPPFLAGS = $(AM_CPPFLAGS)
Added missing tests in CMake, added Makefile.inc for tests (+ use in CMake scripts), and fixed a missing define under windows in a test source file.
2009-04-07 17:59:15 -04:00
lib512_SOURCES = lib512.c $(SUPPORTFILES)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
lib512_CPPFLAGS = $(AM_CPPFLAGS)
Added missing tests in CMake, added Makefile.inc for tests (+ use in CMake scripts), and fixed a missing define under windows in a test source file.
2009-04-07 17:59:15 -04:00
lib513_SOURCES = lib513.c $(SUPPORTFILES)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
lib513_CPPFLAGS = $(AM_CPPFLAGS)
Added missing tests in CMake, added Makefile.inc for tests (+ use in CMake scripts), and fixed a missing define under windows in a test source file.
2009-04-07 17:59:15 -04:00
lib514_SOURCES = lib514.c $(SUPPORTFILES)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
lib514_CPPFLAGS = $(AM_CPPFLAGS)
Added missing tests in CMake, added Makefile.inc for tests (+ use in CMake scripts), and fixed a missing define under windows in a test source file.
2009-04-07 17:59:15 -04:00
lib515_SOURCES = lib515.c $(SUPPORTFILES)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
lib515_CPPFLAGS = $(AM_CPPFLAGS)
Added missing tests in CMake, added Makefile.inc for tests (+ use in CMake scripts), and fixed a missing define under windows in a test source file.
2009-04-07 17:59:15 -04:00
lib516_SOURCES = lib516.c $(SUPPORTFILES)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
lib516_CPPFLAGS = $(AM_CPPFLAGS)
Added missing tests in CMake, added Makefile.inc for tests (+ use in CMake scripts), and fixed a missing define under windows in a test source file.
2009-04-07 17:59:15 -04:00
lib517_SOURCES = lib517.c $(SUPPORTFILES)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
lib517_CPPFLAGS = $(AM_CPPFLAGS)
Added missing tests in CMake, added Makefile.inc for tests (+ use in CMake scripts), and fixed a missing define under windows in a test source file.
2009-04-07 17:59:15 -04:00
test suite: libtest header inclusion cleanup - follow-up Adjust tests/libtest/Makefile.inc and remove a couple of unused headers from tests/libtest/lib583.c
2011-09-06 12:11:11 -04:00
lib518_SOURCES = lib518.c $(SUPPORTFILES) $(WARNLESS)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
lib518_CPPFLAGS = $(AM_CPPFLAGS)
Added missing tests in CMake, added Makefile.inc for tests (+ use in CMake scripts), and fixed a missing define under windows in a test source file.
2009-04-07 17:59:15 -04:00
lib519_SOURCES = lib519.c $(SUPPORTFILES)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
lib519_CPPFLAGS = $(AM_CPPFLAGS)
Added missing tests in CMake, added Makefile.inc for tests (+ use in CMake scripts), and fixed a missing define under windows in a test source file.
2009-04-07 17:59:15 -04:00
lib520_SOURCES = lib520.c $(SUPPORTFILES)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
lib520_CPPFLAGS = $(AM_CPPFLAGS)
Added missing tests in CMake, added Makefile.inc for tests (+ use in CMake scripts), and fixed a missing define under windows in a test source file.
2009-04-07 17:59:15 -04:00
lib521_SOURCES = lib521.c $(SUPPORTFILES)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
lib521_CPPFLAGS = $(AM_CPPFLAGS)
Added missing tests in CMake, added Makefile.inc for tests (+ use in CMake scripts), and fixed a missing define under windows in a test source file.
2009-04-07 17:59:15 -04:00
lib523_SOURCES = lib523.c $(SUPPORTFILES)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
lib523_CPPFLAGS = $(AM_CPPFLAGS)
Added missing tests in CMake, added Makefile.inc for tests (+ use in CMake scripts), and fixed a missing define under windows in a test source file.
2009-04-07 17:59:15 -04:00
lib524_SOURCES = lib524.c $(SUPPORTFILES)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
lib524_CPPFLAGS = $(AM_CPPFLAGS)
Added missing tests in CMake, added Makefile.inc for tests (+ use in CMake scripts), and fixed a missing define under windows in a test source file.
2009-04-07 17:59:15 -04:00
compiler warning: fix Fix compiler warning: variable was set but never used Fix compiler warning: clobber ignored
2011-05-26 06:40:04 -04:00
lib525_SOURCES = lib525.c $(SUPPORTFILES) $(TESTUTIL) $(WARNLESS)
build: prevent global LIBS from influencing libtest build targets
2012-11-30 08:34:48 -05:00
lib525_LDADD = $(TESTUTIL_LIBS)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
lib525_CPPFLAGS = $(AM_CPPFLAGS)
Added missing tests in CMake, added Makefile.inc for tests (+ use in CMake scripts), and fixed a missing define under windows in a test source file.
2009-04-07 17:59:15 -04:00
compiler warning: fix Fix compiler warning: variable was set but never used Fix compiler warning: clobber ignored
2011-05-26 06:40:04 -04:00
lib526_SOURCES = lib526.c $(SUPPORTFILES) $(TESTUTIL) $(WARNLESS)
build: prevent global LIBS from influencing libtest build targets
2012-11-30 08:34:48 -05:00
lib526_LDADD = $(TESTUTIL_LIBS)
makefile: avoid preprocessor definition usage when linking
2011-06-01 08:43:25 -04:00
lib526_CPPFLAGS = $(AM_CPPFLAGS) -DLIB526
Added missing tests in CMake, added Makefile.inc for tests (+ use in CMake scripts), and fixed a missing define under windows in a test source file.
2009-04-07 17:59:15 -04:00
compiler warning: fix Fix compiler warning: variable was set but never used Fix compiler warning: clobber ignored
2011-05-26 06:40:04 -04:00
lib527_SOURCES = lib526.c $(SUPPORTFILES) $(TESTUTIL) $(WARNLESS)
build: prevent global LIBS from influencing libtest build targets
2012-11-30 08:34:48 -05:00
lib527_LDADD = $(TESTUTIL_LIBS)
makefile: avoid preprocessor definition usage when linking
2011-06-01 08:43:25 -04:00
lib527_CPPFLAGS = $(AM_CPPFLAGS) -DLIB527
Added missing tests in CMake, added Makefile.inc for tests (+ use in CMake scripts), and fixed a missing define under windows in a test source file.
2009-04-07 17:59:15 -04:00
compiler warning: fix Fix compiler warning: variable was set but never used Fix compiler warning: clobber ignored
2011-05-26 06:40:04 -04:00
lib529_SOURCES = lib525.c $(SUPPORTFILES) $(TESTUTIL) $(WARNLESS)
build: prevent global LIBS from influencing libtest build targets
2012-11-30 08:34:48 -05:00
lib529_LDADD = $(TESTUTIL_LIBS)
makefile: avoid preprocessor definition usage when linking
2011-06-01 08:43:25 -04:00
lib529_CPPFLAGS = $(AM_CPPFLAGS) -DLIB529
Added missing tests in CMake, added Makefile.inc for tests (+ use in CMake scripts), and fixed a missing define under windows in a test source file.
2009-04-07 17:59:15 -04:00
compiler warning: fix Fix compiler warning: variable was set but never used Fix compiler warning: clobber ignored
2011-05-26 06:40:04 -04:00
lib530_SOURCES = lib530.c $(SUPPORTFILES) $(TESTUTIL) $(WARNLESS)
build: prevent global LIBS from influencing libtest build targets
2012-11-30 08:34:48 -05:00
lib530_LDADD = $(TESTUTIL_LIBS)
makefile: avoid preprocessor definition usage when linking
2011-06-01 08:43:25 -04:00
lib530_CPPFLAGS = $(AM_CPPFLAGS) -DLIB530
Added missing tests in CMake, added Makefile.inc for tests (+ use in CMake scripts), and fixed a missing define under windows in a test source file.
2009-04-07 17:59:15 -04:00
compiler warning: fix Fix compiler warning: variable was set but never used Fix compiler warning: clobber ignored
2011-05-26 06:40:04 -04:00
lib532_SOURCES = lib526.c $(SUPPORTFILES) $(TESTUTIL) $(WARNLESS)
build: prevent global LIBS from influencing libtest build targets
2012-11-30 08:34:48 -05:00
lib532_LDADD = $(TESTUTIL_LIBS)
makefile: avoid preprocessor definition usage when linking
2011-06-01 08:43:25 -04:00
lib532_CPPFLAGS = $(AM_CPPFLAGS) -DLIB532
Added missing tests in CMake, added Makefile.inc for tests (+ use in CMake scripts), and fixed a missing define under windows in a test source file.
2009-04-07 17:59:15 -04:00
compiler warning: fix Fix compiler warning: variable was set but never used Fix compiler warning: clobber ignored
2011-05-26 06:40:04 -04:00
lib533_SOURCES = lib533.c $(SUPPORTFILES) $(TESTUTIL) $(WARNLESS)
build: prevent global LIBS from influencing libtest build targets
2012-11-30 08:34:48 -05:00
lib533_LDADD = $(TESTUTIL_LIBS)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
lib533_CPPFLAGS = $(AM_CPPFLAGS)
Added missing tests in CMake, added Makefile.inc for tests (+ use in CMake scripts), and fixed a missing define under windows in a test source file.
2009-04-07 17:59:15 -04:00
compiler warning: fix Fix compiler warning: variable was set but never used Fix compiler warning: clobber ignored
2011-05-26 06:40:04 -04:00
lib536_SOURCES = lib536.c $(SUPPORTFILES) $(TESTUTIL) $(WARNLESS)
build: prevent global LIBS from influencing libtest build targets
2012-11-30 08:34:48 -05:00
lib536_LDADD = $(TESTUTIL_LIBS)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
lib536_CPPFLAGS = $(AM_CPPFLAGS)
Added missing tests in CMake, added Makefile.inc for tests (+ use in CMake scripts), and fixed a missing define under windows in a test source file.
2009-04-07 17:59:15 -04:00
test suite: libtest header inclusion cleanup - follow-up Adjust tests/libtest/Makefile.inc and remove a couple of unused headers from tests/libtest/lib583.c
2011-09-06 12:11:11 -04:00
lib537_SOURCES = lib537.c $(SUPPORTFILES) $(WARNLESS)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
lib537_CPPFLAGS = $(AM_CPPFLAGS)
Added missing tests in CMake, added Makefile.inc for tests (+ use in CMake scripts), and fixed a missing define under windows in a test source file.
2009-04-07 17:59:15 -04:00
lib539_SOURCES = lib539.c $(SUPPORTFILES)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
lib539_CPPFLAGS = $(AM_CPPFLAGS)
Added missing tests in CMake, added Makefile.inc for tests (+ use in CMake scripts), and fixed a missing define under windows in a test source file.
2009-04-07 17:59:15 -04:00
multi tests: OOM handling fixes Additionally, improved error checking and logging.
2011-10-21 10:26:18 -04:00
lib540_SOURCES = lib540.c $(SUPPORTFILES) $(TESTUTIL) $(WARNLESS)
build: prevent global LIBS from influencing libtest build targets
2012-11-30 08:34:48 -05:00
lib540_LDADD = $(TESTUTIL_LIBS)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
lib540_CPPFLAGS = $(AM_CPPFLAGS)
Added missing tests in CMake, added Makefile.inc for tests (+ use in CMake scripts), and fixed a missing define under windows in a test source file.
2009-04-07 17:59:15 -04:00
lib541_SOURCES = lib541.c $(SUPPORTFILES)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
lib541_CPPFLAGS = $(AM_CPPFLAGS)
Added missing tests in CMake, added Makefile.inc for tests (+ use in CMake scripts), and fixed a missing define under windows in a test source file.
2009-04-07 17:59:15 -04:00
lib542_SOURCES = lib542.c $(SUPPORTFILES)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
lib542_CPPFLAGS = $(AM_CPPFLAGS)
Added missing tests in CMake, added Makefile.inc for tests (+ use in CMake scripts), and fixed a missing define under windows in a test source file.
2009-04-07 17:59:15 -04:00
lib543_SOURCES = lib543.c $(SUPPORTFILES)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
lib543_CPPFLAGS = $(AM_CPPFLAGS)
Added missing tests in CMake, added Makefile.inc for tests (+ use in CMake scripts), and fixed a missing define under windows in a test source file.
2009-04-07 17:59:15 -04:00
lib544_SOURCES = lib544.c $(SUPPORTFILES)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
lib544_CPPFLAGS = $(AM_CPPFLAGS)
Added missing tests in CMake, added Makefile.inc for tests (+ use in CMake scripts), and fixed a missing define under windows in a test source file.
2009-04-07 17:59:15 -04:00
lib545_SOURCES = lib544.c $(SUPPORTFILES)
makefile: avoid preprocessor definition usage when linking
2011-06-01 08:43:25 -04:00
lib545_CPPFLAGS = $(AM_CPPFLAGS) -DLIB545
Added missing tests in CMake, added Makefile.inc for tests (+ use in CMake scripts), and fixed a missing define under windows in a test source file.
2009-04-07 17:59:15 -04:00
lib547_SOURCES = lib547.c $(SUPPORTFILES)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
lib547_CPPFLAGS = $(AM_CPPFLAGS)
Added missing tests in CMake, added Makefile.inc for tests (+ use in CMake scripts), and fixed a missing define under windows in a test source file.
2009-04-07 17:59:15 -04:00
lib548_SOURCES = lib547.c $(SUPPORTFILES)
makefile: avoid preprocessor definition usage when linking
2011-06-01 08:43:25 -04:00
lib548_CPPFLAGS = $(AM_CPPFLAGS) -DLIB548
Added missing tests in CMake, added Makefile.inc for tests (+ use in CMake scripts), and fixed a missing define under windows in a test source file.
2009-04-07 17:59:15 -04:00
lib549_SOURCES = lib549.c $(SUPPORTFILES)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
lib549_CPPFLAGS = $(AM_CPPFLAGS)
Added missing tests in CMake, added Makefile.inc for tests (+ use in CMake scripts), and fixed a missing define under windows in a test source file.
2009-04-07 17:59:15 -04:00
fix several compiler warnings
2012-03-21 21:40:19 -04:00
lib552_SOURCES = lib552.c $(SUPPORTFILES) $(WARNLESS)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
lib552_CPPFLAGS = $(AM_CPPFLAGS)
Added missing tests in CMake, added Makefile.inc for tests (+ use in CMake scripts), and fixed a missing define under windows in a test source file.
2009-04-07 17:59:15 -04:00
lib553_SOURCES = lib553.c $(SUPPORTFILES)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
lib553_CPPFLAGS = $(AM_CPPFLAGS)
Added missing tests in CMake, added Makefile.inc for tests (+ use in CMake scripts), and fixed a missing define under windows in a test source file.
2009-04-07 17:59:15 -04:00
lib554_SOURCES = lib554.c $(SUPPORTFILES)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
lib554_CPPFLAGS = $(AM_CPPFLAGS)
Added missing tests in CMake, added Makefile.inc for tests (+ use in CMake scripts), and fixed a missing define under windows in a test source file.
2009-04-07 17:59:15 -04:00
tests/libtest/Makefile.inc: sort build targets
2013-01-15 10:04:31 -05:00
lib555_SOURCES = lib555.c $(SUPPORTFILES) $(TESTUTIL) $(WARNLESS)
lib555_LDADD = $(TESTUTIL_LIBS)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
lib555_CPPFLAGS = $(AM_CPPFLAGS)
tests/libtest/Makefile.inc: sort build targets
2013-01-15 10:04:31 -05:00
test556: Fixed compilation warning lib556.c:90: warning: conversion to 'unsigned int' from 'size_t' may alter its value
2014-12-28 15:32:46 -05:00
lib556_SOURCES = lib556.c $(SUPPORTFILES) $(WARNLESS)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
lib556_CPPFLAGS = $(AM_CPPFLAGS)
Added missing tests in CMake, added Makefile.inc for tests (+ use in CMake scripts), and fixed a missing define under windows in a test source file.
2009-04-07 17:59:15 -04:00
lib557_SOURCES = lib557.c $(SUPPORTFILES)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
lib557_CPPFLAGS = $(AM_CPPFLAGS)
Added missing tests in CMake, added Makefile.inc for tests (+ use in CMake scripts), and fixed a missing define under windows in a test source file.
2009-04-07 17:59:15 -04:00
tests: add #96 #558 and #1330 These verfy that the 'memory tracking' subsystem is actually doing its job when using curl tool (#96), a test in libtest (#558) and also a unit test (#1330), in order to prevent regressions in this functionallity.
2013-03-15 14:58:00 -04:00
lib558_SOURCES = lib558.c $(SUPPORTFILES)
lib558_CPPFLAGS = $(AM_CPPFLAGS)
test559: verify use of minimum CURLOPT_BUFFERSIZE
2017-05-04 09:39:04 -04:00
lib559_SOURCES = lib559.c $(SUPPORTFILES)
lib559_CPPFLAGS = $(AM_CPPFLAGS)
multi tests: OOM handling fixes Additionally, improved error checking and logging.
2011-10-21 10:26:18 -04:00
lib560_SOURCES = lib560.c $(SUPPORTFILES) $(TESTUTIL) $(WARNLESS)
build: prevent global LIBS from influencing libtest build targets
2012-11-30 08:34:48 -05:00
lib560_LDADD = $(TESTUTIL_LIBS)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
lib560_CPPFLAGS = $(AM_CPPFLAGS)
- I was going to fix issue #59 in KNOWN_BUGS If the CURLOPT_PORT option is used on an FTP URL like "ftp://example.com/file;type=A" the ";type=A" is stripped off. I added test case 562 to verify, only to find out that I couldn't repeat this bug so I hereby consider it not a bug anymore!
2009-04-30 05:02:39 -04:00
lib562_SOURCES = lib562.c $(SUPPORTFILES)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
lib562_CPPFLAGS = $(AM_CPPFLAGS)
Added test 564 as DISABLED. It is for testing FTP over a SOCK4 proxy using the multi interface, which currently doesn't work because of how the data connection is not waiting for connect before it tries to do proxy magic.
2009-05-11 07:43:55 -04:00
compiler warning: fix Fix compiler warning: variable was set but never used Fix compiler warning: clobber ignored
2011-05-26 06:40:04 -04:00
lib564_SOURCES = lib564.c $(SUPPORTFILES) $(TESTUTIL) $(WARNLESS)
build: prevent global LIBS from influencing libtest build targets
2012-11-30 08:34:48 -05:00
lib564_LDADD = $(TESTUTIL_LIBS)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
lib564_CPPFLAGS = $(AM_CPPFLAGS)
- "Tom" posted a bug report that mentioned how libcurl did wrong when doing a POST using a read callback, with Digest authentication and "Transfer-Encoding: chunked" enforced. I would then cause the first request to be wrongly sent and then basically hang until the server closed the connection. I fixed the problem and added test case 565 to verify it.
2009-10-30 18:24:48 -04:00
lib565_SOURCES = lib510.c $(SUPPORTFILES)
makefile: avoid preprocessor definition usage when linking
2011-06-01 08:43:25 -04:00
lib565_CPPFLAGS = $(AM_CPPFLAGS) -DLIB565
Added test case 566 in an attempt to repeat bug 2884561 (http://curl.haxx.se/bug/view.cgi?id=2884561) but it seems to work for me...
2009-10-30 18:38:21 -04:00
lib566_SOURCES = lib566.c $(SUPPORTFILES)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
lib566_CPPFLAGS = $(AM_CPPFLAGS)
Chris Conroy provided first RTSP tests
2010-01-27 23:58:03 -05:00
lib567_SOURCES = lib567.c $(SUPPORTFILES)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
lib567_CPPFLAGS = $(AM_CPPFLAGS)
Chris Conroy provided first RTSP tests
2010-01-27 23:58:03 -05:00
lib568_SOURCES = lib568.c $(SUPPORTFILES)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
lib568_CPPFLAGS = $(AM_CPPFLAGS)
Chris Conroy provided first RTSP tests
2010-01-27 23:58:03 -05:00
lib569_SOURCES = lib569.c $(SUPPORTFILES)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
lib569_CPPFLAGS = $(AM_CPPFLAGS)
Chris Conroy provided first RTSP tests
2010-01-27 23:58:03 -05:00
lib570_SOURCES = lib570.c $(SUPPORTFILES)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
lib570_CPPFLAGS = $(AM_CPPFLAGS)
Chris Conroy provided first RTSP tests
2010-01-27 23:58:03 -05:00
fix several compiler warnings
2012-03-21 21:40:19 -04:00
lib571_SOURCES = lib571.c $(SUPPORTFILES) $(WARNLESS)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
lib571_CPPFLAGS = $(AM_CPPFLAGS)
Chris Conroy provided first RTSP tests
2010-01-27 23:58:03 -05:00
Fix RTSP GET_PARAMETER empty and non-empty operation. Test coverage included. Thanks to Massimo Callegari for the bug report
2010-03-24 01:35:03 -04:00
lib572_SOURCES = lib572.c $(SUPPORTFILES)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
lib572_CPPFLAGS = $(AM_CPPFLAGS)
Fix RTSP GET_PARAMETER empty and non-empty operation. Test coverage included. Thanks to Massimo Callegari for the bug report
2010-03-24 01:35:03 -04:00
tests: enable time tracing on tests 500, 573 and 585
2012-01-17 15:33:17 -05:00
lib573_SOURCES = lib573.c $(SUPPORTFILES) $(TESTUTIL) $(WARNLESS) $(TSTTRACE)
build: prevent global LIBS from influencing libtest build targets
2012-11-30 08:34:48 -05:00
lib573_LDADD = $(TESTUTIL_LIBS)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
lib573_CPPFLAGS = $(AM_CPPFLAGS)
progress: callback for POSTs less than MAX_INITIAL_POST_SIZE Add a call to Curl_pgrsSetUploadSize in this case valided by a test case. Reported by: Никита Дорохин. Bug: http://curl.haxx.se/mail/lib-2010-04/0173.html
2010-08-16 16:54:19 -04:00
tests/libtest/Makefile.inc: sort build targets
2013-01-15 10:04:31 -05:00
lib574_SOURCES = lib574.c $(SUPPORTFILES)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
lib574_CPPFLAGS = $(AM_CPPFLAGS)
tests/libtest/Makefile.inc: sort build targets
2013-01-15 10:04:31 -05:00
lib575_SOURCES = lib575.c $(SUPPORTFILES) $(TESTUTIL) $(WARNLESS)
lib575_LDADD = $(TESTUTIL_LIBS)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
lib575_CPPFLAGS = $(AM_CPPFLAGS)
tests/libtest/Makefile.inc: sort build targets
2013-01-15 10:04:31 -05:00
lib576_SOURCES = lib576.c $(SUPPORTFILES)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
lib576_CPPFLAGS = $(AM_CPPFLAGS)
tests/libtest/Makefile.inc: sort build targets
2013-01-15 10:04:31 -05:00
progress: callback for POSTs less than MAX_INITIAL_POST_SIZE Add a call to Curl_pgrsSetUploadSize in this case valided by a test case. Reported by: Никита Дорохин. Bug: http://curl.haxx.se/mail/lib-2010-04/0173.html
2010-08-16 16:54:19 -04:00
lib578_SOURCES = lib578.c $(SUPPORTFILES)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
lib578_CPPFLAGS = $(AM_CPPFLAGS)
test: added test 579 to verify progress callback for chunked post The 66 bytes checked are those 38 bytes with the chunked encoding headers added: 8+8+10+35+5 = 66 The three-letter words become 8 bytes on the wire because they are sent like: "3\r\none\r\n" ... and there's the trailing 5 bytes write after the four lines since the final chunk is sent (which is "0\r\n\r\n").
2010-08-18 18:27:04 -04:00
lib579_SOURCES = lib579.c $(SUPPORTFILES)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
lib579_CPPFLAGS = $(AM_CPPFLAGS)
unittest: framework for unit-testing This is the first approach at doing fairly clean and easy to write and debug unit tests.
2011-01-01 11:33:42 -05:00
compiler warning: fix Fix compiler warning: variable was set but never used Fix compiler warning: clobber ignored
2011-05-26 06:40:04 -04:00
lib582_SOURCES = lib582.c $(SUPPORTFILES) $(TESTUTIL) $(WARNLESS)
build: prevent global LIBS from influencing libtest build targets
2012-11-30 08:34:48 -05:00
lib582_LDADD = $(TESTUTIL_LIBS)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
lib582_CPPFLAGS = $(AM_CPPFLAGS)
sftp-multi: test 582 added Add test 582 for uploading a file using sftp and the multi interface. (Patch and test slightly tweaked by Daniel Stenberg) Initially marked as disabled until it is fixed in the source.
2011-03-07 18:19:49 -05:00
test583: verify early SSH multi remove handle This test case is meant to verify that the logic in commit 60172a0446bbe3f8b actually works. This test failed for me before that change and it works after it.
2011-03-12 18:18:04 -05:00
lib583_SOURCES = lib583.c $(SUPPORTFILES)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
lib583_CPPFLAGS = $(AM_CPPFLAGS)
tests: verify OPEN/CLOSESOCKETFUNCTION Test 585 and 586 were added. Using a modified lib500.c
2011-05-18 15:48:14 -04:00
tests: enable time tracing on tests 500, 573 and 585
2012-01-17 15:33:17 -05:00
lib585_SOURCES = lib500.c $(SUPPORTFILES) $(TESTUTIL) $(TSTTRACE)
build: prevent global LIBS from influencing libtest build targets
2012-11-30 08:34:48 -05:00
lib585_LDADD = $(TESTUTIL_LIBS)
makefile: avoid preprocessor definition usage when linking
2011-06-01 08:43:25 -04:00
lib585_CPPFLAGS = $(AM_CPPFLAGS) -DLIB585
formdata: ack read callback abort When doing a multipart formpost with a read callback, and that callback returns CURL_READFUNC_ABORT, that return code must be properly propagated back and handled accordingly. Previously it would be handled as a zero byte read which would cause a hang! Added test case 587 to verify. It uses the lib554.c source code with a small ifdef. Reported by: Anton Bychkov Bug: http://curl.haxx.se/mail/lib-2011-10/0097.html
2011-10-15 19:07:29 -04:00
libtest build: add the missing lib586
2011-11-17 17:33:42 -05:00
lib586_SOURCES = lib586.c $(SUPPORTFILES)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
lib586_CPPFLAGS = $(AM_CPPFLAGS)
libtest build: add the missing lib586
2011-11-17 17:33:42 -05:00
formdata: ack read callback abort When doing a multipart formpost with a read callback, and that callback returns CURL_READFUNC_ABORT, that return code must be properly propagated back and handled accordingly. Previously it would be handled as a zero byte read which would cause a hang! Added test case 587 to verify. It uses the lib554.c source code with a small ifdef. Reported by: Anton Bychkov Bug: http://curl.haxx.se/mail/lib-2011-10/0097.html
2011-10-15 19:07:29 -04:00
lib587_SOURCES = lib554.c $(SUPPORTFILES)
lib587_CPPFLAGS = $(AM_CPPFLAGS) -DLIB587
test 589: active FTP upload using multi timeout and EPRT disabled server
2011-10-26 12:55:35 -04:00
test 590: verify the bug fix in 4851dafcf1 This test is created to verify Rene Bernhardt's patch which makes sure libcurl properly _not_ deals with Negotiate if not asked to even if the proxy says it can serve it.
2011-11-06 11:28:28 -05:00
lib590_SOURCES = lib590.c $(SUPPORTFILES)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
lib590_CPPFLAGS = $(AM_CPPFLAGS)
Active mode FTP test cases with server not establishing data connection 591 -> FTP multi PORT and 425 on upload 592 -> FTP multi PORT and 421 on upload 593 -> FTP multi PORT upload, no data conn and no transient neg. reply 594 -> FTP multi PORT upload, no data conn and no positive prelim. reply 1206 -> FTP PORT and 425 on download 1207 -> FTP PORT and 421 on download 1208 -> FTP PORT download, no data conn and no transient negative reply 1209 -> FTP PORT download, no data conn and no positive preliminary reply
2011-11-11 13:46:44 -05:00
lib591_SOURCES = lib591.c $(SUPPORTFILES) $(TESTUTIL) $(WARNLESS)
build: prevent global LIBS from influencing libtest build targets
2012-11-30 08:34:48 -05:00
lib591_LDADD = $(TESTUTIL_LIBS)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
lib591_CPPFLAGS = $(AM_CPPFLAGS)
multi interface: fix block when CONNECT_ONLY option is used
2011-12-06 17:41:24 -05:00
lib597_SOURCES = lib597.c $(SUPPORTFILES) $(TESTUTIL) $(WARNLESS)
build: prevent global LIBS from influencing libtest build targets
2012-11-30 08:34:48 -05:00
lib597_LDADD = $(TESTUTIL_LIBS)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
lib597_CPPFLAGS = $(AM_CPPFLAGS)
curl_easy_reset: reset the referer string When CURLOPT_REFERER has been used, curl_easy_reset() did not properly clear it. Verified with the new test 598 Bug: http://curl.haxx.se/bug/view.cgi?id=3481551 Reported by: Michael Day
2012-02-06 16:59:49 -05:00
lib598_SOURCES = lib598.c $(SUPPORTFILES)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
lib598_CPPFLAGS = $(AM_CPPFLAGS)
HTTP: reset expected DL/UL sizes on redirects With FOLLOWLOCATION enabled. When a 3xx page is downloaded and the download size was known (like with a Content-Length header), but the subsequent URL (transfered after the 3xx page) was chunked encoded, then the previous "known download size" would linger and cause the progress meter to get incorrect information, ie the former value would remain being sent in. This could easily result in downloads that were WAY larger than "expected" and would cause >100% outputs with the curl command line tool. Test case 599 was created and it was used to repeat the bug and then verify the fix. Bug: http://curl.haxx.se/bug/view.cgi?id=3510057 Reported by: Michael Wallner
2012-03-23 18:42:37 -04:00
lib599_SOURCES = lib599.c $(SUPPORTFILES)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
lib599_CPPFLAGS = $(AM_CPPFLAGS)
Add tests of auth retries
2012-07-19 13:58:10 -04:00
Unit test for curl_multi_wait()
2012-09-01 17:27:11 -04:00
lib1500_SOURCES = lib1500.c $(SUPPORTFILES) $(TESTUTIL)
build: prevent global LIBS from influencing libtest build targets
2012-11-30 08:34:48 -05:00
lib1500_LDADD = $(TESTUTIL_LIBS)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
lib1500_CPPFLAGS = $(AM_CPPFLAGS)
Unit test for curl_multi_wait()
2012-09-01 17:27:11 -04:00
Fix compilation of lib1501
2012-11-08 10:36:55 -05:00
lib1501_SOURCES = lib1501.c $(SUPPORTFILES) $(TESTUTIL) $(WARNLESS)
build: prevent global LIBS from influencing libtest build targets
2012-11-30 08:34:48 -05:00
lib1501_LDADD = $(TESTUTIL_LIBS)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
lib1501_CPPFLAGS = $(AM_CPPFLAGS)
FTP: prevent the multi interface from blocking As pointed out in Bug report #3579064, curl_multi_perform() would wrongly use a blocking mechanism internally for some commands which could lead to for example a very long block if the LIST response never showed. The solution was to make sure to properly continue to use the multi interface non-blocking state machine. The new test 1501 verifies the fix. Bug: http://curl.haxx.se/bug/view.cgi?id=3579064 Reported by: Guido Berhoerster
2012-11-04 12:22:48 -05:00
test 1502: OOM handling fixes
2012-12-23 15:22:03 -05:00
lib1502_SOURCES = lib1502.c $(SUPPORTFILES) $(TESTUTIL) $(WARNLESS)
lib1502_LDADD = $(TESTUTIL_LIBS)
test 1503: same as 1502 but with a different cleanup sequence
2012-12-23 15:33:26 -05:00
lib1502_CPPFLAGS = $(AM_CPPFLAGS) -DLIB1502
lib1503_SOURCES = lib1502.c $(SUPPORTFILES) $(TESTUTIL) $(WARNLESS)
lib1503_LDADD = $(TESTUTIL_LIBS)
lib1503_CPPFLAGS = $(AM_CPPFLAGS) -DLIB1503
fixed memory leak: CURLOPT_RESOLVE with multi interface DNS cache entries populated with CURLOPT_RESOLVE were not properly freed again when done using the multi interface. Test case 1502 added to verify. Bug: http://curl.haxx.se/bug/view.cgi?id=3575448 Reported by: Alex Gruz
2012-11-18 10:17:37 -05:00
test 1504 and 1505: same as 1502 but with different cleanup sequences
2012-12-24 08:04:34 -05:00
lib1504_SOURCES = lib1502.c $(SUPPORTFILES) $(TESTUTIL) $(WARNLESS)
lib1504_LDADD = $(TESTUTIL_LIBS)
lib1504_CPPFLAGS = $(AM_CPPFLAGS) -DLIB1504
lib1505_SOURCES = lib1502.c $(SUPPORTFILES) $(TESTUTIL) $(WARNLESS)
lib1505_LDADD = $(TESTUTIL_LIBS)
lib1505_CPPFLAGS = $(AM_CPPFLAGS) -DLIB1505
CURLMOPT_MAXCONNECTS: restore functionality When a connection is no longer used, it is kept in the cache. If the cache is full, the oldest idle connection is closed. If no connection is idle, the current one is closed instead.
2013-02-05 03:07:27 -05:00
lib1506_SOURCES = lib1506.c $(SUPPORTFILES) $(TESTUTIL) $(WARNLESS)
lib1506_LDADD = $(TESTUTIL_LIBS)
lib1506_CPPFLAGS = $(AM_CPPFLAGS) -DLIB1506
DONE: consider callback-aborted transfers premature This bug report properly identified that when doing SMTP and aborting the transfer with a callback, it must be considered aborted prematurely by the code to avoid QUIT etc to be attempted as that would cause a hang. The new test case 1507 verifies this behavior. Reported by: Patricia Muscalu Bug: http://curl.haxx.se/bug/view.cgi?id=1184
2013-02-08 07:48:56 -05:00
lib1507_SOURCES = lib1507.c $(SUPPORTFILES) $(TESTUTIL) $(WARNLESS)
lib1507_LDADD = $(TESTUTIL_LIBS)
lib1507_CPPFLAGS = $(AM_CPPFLAGS) -DLIB1507
Fix NULL pointer reference when closing an unused multi handle.
2013-02-10 16:57:58 -05:00
lib1508_SOURCES = lib1508.c $(SUPPORTFILES) $(TESTUTIL) $(WARNLESS)
lib1508_LDADD = $(TESTUTIL_LIBS)
lib1508_CPPFLAGS = $(AM_CPPFLAGS) -DLIB1508
Multiple pipelines and limiting the number of connections. Introducing a number of options to the multi interface that allows for multiple pipelines to the same host, in order to optimize the balance between the penalty for opening new connections and the potential pipelining latency. Two new options for limiting the number of connections: CURLMOPT_MAX_HOST_CONNECTIONS - Limits the number of running connections to the same host. When adding a handle that exceeds this limit, that handle will be put in a pending state until another handle is finished, so we can reuse the connection. CURLMOPT_MAX_TOTAL_CONNECTIONS - Limits the number of connections in total. When adding a handle that exceeds this limit, that handle will be put in a pending state until another handle is finished. The free connection will then be reused, if possible, or closed if the pending handle can't reuse it. Several new options for pipelining: CURLMOPT_MAX_PIPELINE_LENGTH - Limits the pipeling length. If a pipeline is "full" when a connection is to be reused, a new connection will be opened if the CURLMOPT_MAX_xxx_CONNECTIONS limits allow it. If not, the handle will be put in a pending state until a connection is ready (either free or a pipe got shorter). CURLMOPT_CONTENT_LENGTH_PENALTY_SIZE - A pipelined connection will not be reused if it is currently processing a transfer with a content length that is larger than this. CURLMOPT_CHUNK_LENGTH_PENALTY_SIZE - A pipelined connection will not be reused if it is currently processing a chunk larger than this. CURLMOPT_PIPELINING_SITE_BL - A blacklist of hosts that don't allow pipelining. CURLMOPT_PIPELINING_SERVER_BL - A blacklist of server types that don't allow pipelining. See the curl_multi_setopt() man page for details.
2013-02-15 05:50:45 -05:00
test1509: verify proxy header response headers count Modified sws to support and use custom CONNECT responses instead of the previously naive hard-coded version. Made the HTTP test server able to extract test case number from the host name in a CONNECT request by finding the number after the last dot. It makes 'machine.moo.123' use test case 123. Adapted a larger amount of tests to the new <connect> style. Bug: http://curl.haxx.se/bug/view.cgi?id=1204 Reported by: Martin Jansen
2013-03-15 12:28:32 -04:00
lib1509_SOURCES = lib1509.c $(SUPPORTFILES) $(TESTUTIL) $(WARNLESS)
lib1509_LDADD = $(TESTUTIL_LIBS)
lib1509_CPPFLAGS = $(AM_CPPFLAGS) -DLIB1509
easy: Fix the broken CURLOPT_MAXCONNECTS option Copy the CURLOPT_MAXCONNECTS option to CURLMOPT_MAXCONNECTS in curl_easy_perform(). Bug: http://curl.haxx.se/bug/view.cgi?id=1212 Reported-by: Steven Gu
2013-04-04 04:33:39 -04:00
lib1510_SOURCES = lib1510.c $(SUPPORTFILES) $(TESTUTIL) $(WARNLESS)
lib1510_LDADD = $(TESTUTIL_LIBS)
lib1510_CPPFLAGS = $(AM_CPPFLAGS) -DLIB1510
tests: add test1511 to check timecond clean-up Verifies the timecond fix in commit c49ed0b6c0f
2013-04-22 14:07:15 -04:00
lib1511_SOURCES = lib1511.c $(SUPPORTFILES) $(TESTUTIL) $(WARNLESS)
lib1511_LDADD = $(TESTUTIL_LIBS)
lib1511_CPPFLAGS = $(AM_CPPFLAGS) -DLIB1511
global dns cache: didn't work [regression] CURLOPT_DNS_USE_GLOBAL_CACHE broke in commit c43127414d89ccb (been broken since the libcurl 7.29.0 release). While this option has been documented as deprecated for almost a decade and nobody even reported this bug, it should remain functional. Added test case 1512 to verify
2013-08-08 07:01:16 -04:00
lib1512_SOURCES = lib1512.c $(SUPPORTFILES) $(TESTUTIL) $(WARNLESS)
lib1512_LDADD = $(TESTUTIL_LIBS)
lib1512_CPPFLAGS = $(AM_CPPFLAGS) -DLIB1512
test1513: added - verify early progress callback return fail Verify the change brought in commit 8e11731653061. It makes sure that returning a failure from the progress callback even very early results in the correct return code.
2014-01-03 06:25:09 -05:00
lib1513_SOURCES = lib1513.c $(SUPPORTFILES) $(TESTUTIL) $(WARNLESS)
lib1513_LDADD = $(TESTUTIL_LIBS)
lib1513_CPPFLAGS = $(AM_CPPFLAGS) -DLIB1513
test1514: added - no more negative Content-Length (HTTP POST) This covers changes from commit afd288b2.
2014-01-19 17:25:32 -05:00
lib1514_SOURCES = lib1514.c $(SUPPORTFILES) $(TESTUTIL) $(WARNLESS)
lib1514_LDADD = $(TESTUTIL_LIBS)
lib1514_CPPFLAGS = $(AM_CPPFLAGS) -DLIB1514
tests: add test for bug #1303 (dns cache timeout) Test-case 1515 reproduces bug #1303, where libcurl would incorrectly prune DNS entries added via CURLOPT_RESOLVE after the DNS_CACHE_TIMEOUT had expired.
2014-01-31 14:03:13 -05:00
lib1515_SOURCES = lib1515.c $(SUPPORTFILES) $(TESTUTIL) $(WARNLESS)
lib1515_LDADD = $(TESTUTIL_LIBS)
CURLOPT_PROXYHEADER: set headers for proxy-only Includes docs and new test cases: 1525, 1526 and 1527 Co-written-by: Vijay Panghal
2014-01-31 02:10:07 -05:00
lib1515_CPPFLAGS = $(AM_CPPFLAGS) -DLIB1515
tests: added test1517 ... for checking ability to receive full HTTP response when POST request is used with slow read callback function. This test checks for bug #657 and verifies the work-around from 72d5e144fbc6. Closes #720
2016-03-17 13:04:20 -04:00
lib1517_SOURCES = lib1517.c $(SUPPORTFILES)
lib1517_CPPFLAGS = $(AM_CPPFLAGS) -DLIB1517
tests: Added test for bug #1456
2014-12-28 07:12:09 -05:00
lib1520_SOURCES = lib1520.c $(SUPPORTFILES)
lib1520_CPPFLAGS = $(AM_CPPFLAGS) -DLIB1520
CURLOPT_PROXYHEADER: set headers for proxy-only Includes docs and new test cases: 1525, 1526 and 1527 Co-written-by: Vijay Panghal
2014-01-31 02:10:07 -05:00
lib1525_SOURCES = lib1525.c $(SUPPORTFILES) $(TESTUTIL) $(WARNLESS)
lib1525_LDADD = $(TESTUTIL_LIBS)
lib1525_CPPFLAGS = $(AM_CPPFLAGS) -DLIB1525
lib1526_SOURCES = lib1526.c $(SUPPORTFILES) $(TESTUTIL) $(WARNLESS)
lib1526_LDADD = $(TESTUTIL_LIBS)
lib1526_CPPFLAGS = $(AM_CPPFLAGS) -DLIB1526
lib1527_SOURCES = lib1527.c $(SUPPORTFILES) $(TESTUTIL) $(WARNLESS)
lib1527_LDADD = $(TESTUTIL_LIBS)
lib1527_CPPFLAGS = $(AM_CPPFLAGS) -DLIB1527
tests: add test for bug #1303 (dns cache timeout) Test-case 1515 reproduces bug #1303, where libcurl would incorrectly prune DNS entries added via CURLOPT_RESOLVE after the DNS_CACHE_TIMEOUT had expired.
2014-01-31 14:03:13 -05:00
PROXYHEADER: send these headers in "normal" proxy requests too Updated the docs to clarify and the code accordingly, with test 1528 to verify: When CURLHEADER_SEPARATE is set and libcurl is asked to send a request to a proxy but it isn't CONNECT, then _both_ header lists (CURLOPT_HTTPHEADER and CURLOPT_PROXYHEADER) will be used since the single request is then made for both the proxy and the server.
2014-02-20 11:10:00 -05:00
lib1528_SOURCES = lib1528.c $(SUPPORTFILES) $(TESTUTIL) $(WARNLESS)
lib1528_LDADD = $(TESTUTIL_LIBS)
lib1528_CPPFLAGS = $(AM_CPPFLAGS) -DLIB1528
tests: make sure CRLFs can't be used in URLs passed to proxy Bug: http://curl.haxx.se/docs/adv_20150108B.html
2014-12-25 17:51:43 -05:00
lib1529_SOURCES = lib1529.c $(SUPPORTFILES) $(TESTUTIL) $(WARNLESS)
lib1529_LDADD = $(TESTUTIL_LIBS)
lib1529_CPPFLAGS = $(AM_CPPFLAGS) -DLIB1529
CURLOPT_OPENSOCKETFUNCTION: return error at once When CURL_SOCKET_BAD is returned in the callback, it should be treated as an error (CURLE_COULDNT_CONNECT) if no other socket is subsequently created when trying to connect to a server. Bug: http://curl.haxx.se/mail/lib-2015-06/0047.html
2015-06-08 18:22:02 -04:00
lib1530_SOURCES = lib1530.c $(SUPPORTFILES) $(TESTUTIL) $(WARNLESS)
lib1530_LDADD = $(TESTUTIL_LIBS)
lib1530_CPPFLAGS = $(AM_CPPFLAGS) -DLIB1530
test1531: verify POSTFIELDSIZE set after add_handle Following the fix made in 903b6e05565bf.
2015-06-23 20:51:03 -04:00
lib1531_SOURCES = lib1531.c $(SUPPORTFILES) $(TESTUTIL) $(WARNLESS)
lib1531_LDADD = $(TESTUTIL_LIBS)
lib1531_CPPFLAGS = $(AM_CPPFLAGS) -DLIB1531
easy: Reset all statistical session info in curl_easy_reset Bug: https://github.com/curl/curl/issues/1017 Reported-by: Jeroen Ooms
2016-09-17 01:48:20 -04:00
lib1532_SOURCES = lib1532.c $(SUPPORTFILES) $(TESTUTIL) $(WARNLESS)
lib1532_LDADD = $(TESTUTIL_LIBS)
lib1532_CPPFLAGS = $(AM_CPPFLAGS) -DLIB1532
New libcurl option to keep sending on error Add the new option CURLOPT_KEEP_SENDING_ON_ERROR to control whether sending the request body shall be completed when the server responds early with an error status code. This is suitable for manual NTLM authentication. Reviewed-by: Jay Satiro Closes https://github.com/curl/curl/pull/904
2016-09-22 16:15:13 -04:00
lib1533_SOURCES = lib1533.c $(SUPPORTFILES) $(TESTUTIL) $(WARNLESS)
lib1533_LDADD = $(TESTUTIL_LIBS)
lib1533_CPPFLAGS = $(AM_CPPFLAGS) -DLIB1533
easy: Initialize info variables on easy init and duphandle - Call Curl_initinfo on init and duphandle. Prior to this change the statistical and informational variables were simply zeroed by calloc on easy init and duphandle. While zero is the correct default value for almost all info variables, there is one where it isn't (filetime initializes to -1). Bug: https://github.com/curl/curl/issues/1103 Reported-by: Neal Poole
2016-11-05 23:05:52 -04:00
lib1534_SOURCES = lib1534.c $(SUPPORTFILES) $(TESTUTIL) $(WARNLESS)
lib1534_LDADD = $(TESTUTIL_LIBS)
lib1534_CPPFLAGS = $(AM_CPPFLAGS) -DLIB1534
tests: Add some testcases for recent new features. Add missing tests for CURLINFO_SCHEME, CURLINFO_PROTOCOL, %{scheme}, and %{http_version} closes #1143
2016-11-25 16:32:32 -05:00
lib1535_SOURCES = lib1535.c $(SUPPORTFILES) $(TESTUTIL) $(WARNLESS)
lib1535_LDADD = $(TESTUTIL_LIBS)
lib1535_CPPFLAGS = $(AM_CPPFLAGS) -DLIB1535
lib1536_SOURCES = lib1536.c $(SUPPORTFILES) $(TESTUTIL) $(WARNLESS)
lib1536_LDADD = $(TESTUTIL_LIBS)
lib1536_CPPFLAGS = $(AM_CPPFLAGS) -DLIB1536
pause: handle mixed types of data when paused When receiving chunked encoded data with trailers, and the write callback returns PAUSE, there might be both body and header to store to resend on unpause. Previously libcurl returned error for that case. Added test case 1540 to verify. Reported-by: Stephen Toub Fixes #1354 Closes #1357
2017-03-27 06:14:57 -04:00
lib1540_SOURCES = lib1540.c $(SUPPORTFILES) $(TESTUTIL) $(WARNLESS)
lib1540_LDADD = $(TESTUTIL_LIBS)
lib1540_CPPFLAGS = $(AM_CPPFLAGS)
include: curl/system.h is a run-time version of curlbuild.h system.h is aimed to replace curlbuild.h at a later point in time when we feel confident system.h works sufficiently well. curl/system.h is currently used in parallel with curl/curlbuild.h curl/system.h determines a data sizes, data types and include file status based on available preprocessor defines instead of getting generated at build-time. This, in order to avoid relying on a build-time generated file that makes it complicated to do 32 and 64 bit bields from the same installed set of headers. Test 1541 verifies that system.h comes to the same conclusion that curlbuild.h offers. Closes #1373
2017-03-29 08:38:56 -04:00
lib1541_SOURCES = lib1541.c $(SUPPORTFILES) $(TESTUTIL) $(WARNLESS)
lib1541_LDADD = $(TESTUTIL_LIBS)
lib1541_CPPFLAGS = $(AM_CPPFLAGS)
Multiple pipelines and limiting the number of connections. Introducing a number of options to the multi interface that allows for multiple pipelines to the same host, in order to optimize the balance between the penalty for opening new connections and the potential pipelining latency. Two new options for limiting the number of connections: CURLMOPT_MAX_HOST_CONNECTIONS - Limits the number of running connections to the same host. When adding a handle that exceeds this limit, that handle will be put in a pending state until another handle is finished, so we can reuse the connection. CURLMOPT_MAX_TOTAL_CONNECTIONS - Limits the number of connections in total. When adding a handle that exceeds this limit, that handle will be put in a pending state until another handle is finished. The free connection will then be reused, if possible, or closed if the pending handle can't reuse it. Several new options for pipelining: CURLMOPT_MAX_PIPELINE_LENGTH - Limits the pipeling length. If a pipeline is "full" when a connection is to be reused, a new connection will be opened if the CURLMOPT_MAX_xxx_CONNECTIONS limits allow it. If not, the handle will be put in a pending state until a connection is ready (either free or a pipe got shorter). CURLMOPT_CONTENT_LENGTH_PENALTY_SIZE - A pipelined connection will not be reused if it is currently processing a transfer with a content length that is larger than this. CURLMOPT_CHUNK_LENGTH_PENALTY_SIZE - A pipelined connection will not be reused if it is currently processing a chunk larger than this. CURLMOPT_PIPELINING_SITE_BL - A blacklist of hosts that don't allow pipelining. CURLMOPT_PIPELINING_SERVER_BL - A blacklist of server types that don't allow pipelining. See the curl_multi_setopt() man page for details.
2013-02-15 05:50:45 -05:00
lib1900_SOURCES = lib1900.c $(SUPPORTFILES) $(TESTUTIL) $(WARNLESS)
Add extra libs for lib1900 and lib2033 test programs These are needed in cases where clock_gettime is used, from librt.
2013-04-15 05:14:30 -04:00
lib1900_LDADD = $(TESTUTIL_LIBS)
Multiple pipelines and limiting the number of connections. Introducing a number of options to the multi interface that allows for multiple pipelines to the same host, in order to optimize the balance between the penalty for opening new connections and the potential pipelining latency. Two new options for limiting the number of connections: CURLMOPT_MAX_HOST_CONNECTIONS - Limits the number of running connections to the same host. When adding a handle that exceeds this limit, that handle will be put in a pending state until another handle is finished, so we can reuse the connection. CURLMOPT_MAX_TOTAL_CONNECTIONS - Limits the number of connections in total. When adding a handle that exceeds this limit, that handle will be put in a pending state until another handle is finished. The free connection will then be reused, if possible, or closed if the pending handle can't reuse it. Several new options for pipelining: CURLMOPT_MAX_PIPELINE_LENGTH - Limits the pipeling length. If a pipeline is "full" when a connection is to be reused, a new connection will be opened if the CURLMOPT_MAX_xxx_CONNECTIONS limits allow it. If not, the handle will be put in a pending state until a connection is ready (either free or a pipe got shorter). CURLMOPT_CONTENT_LENGTH_PENALTY_SIZE - A pipelined connection will not be reused if it is currently processing a transfer with a content length that is larger than this. CURLMOPT_CHUNK_LENGTH_PENALTY_SIZE - A pipelined connection will not be reused if it is currently processing a chunk larger than this. CURLMOPT_PIPELINING_SITE_BL - A blacklist of hosts that don't allow pipelining. CURLMOPT_PIPELINING_SERVER_BL - A blacklist of server types that don't allow pipelining. See the curl_multi_setopt() man page for details.
2013-02-15 05:50:45 -05:00
lib1900_CPPFLAGS = $(AM_CPPFLAGS)
lib2033_SOURCES = libntlmconnect.c $(SUPPORTFILES) $(TESTUTIL) $(WARNLESS)
Add extra libs for lib1900 and lib2033 test programs These are needed in cases where clock_gettime is used, from librt.
2013-04-15 05:14:30 -04:00
lib2033_LDADD = $(TESTUTIL_LIBS)
Multiple pipelines and limiting the number of connections. Introducing a number of options to the multi interface that allows for multiple pipelines to the same host, in order to optimize the balance between the penalty for opening new connections and the potential pipelining latency. Two new options for limiting the number of connections: CURLMOPT_MAX_HOST_CONNECTIONS - Limits the number of running connections to the same host. When adding a handle that exceeds this limit, that handle will be put in a pending state until another handle is finished, so we can reuse the connection. CURLMOPT_MAX_TOTAL_CONNECTIONS - Limits the number of connections in total. When adding a handle that exceeds this limit, that handle will be put in a pending state until another handle is finished. The free connection will then be reused, if possible, or closed if the pending handle can't reuse it. Several new options for pipelining: CURLMOPT_MAX_PIPELINE_LENGTH - Limits the pipeling length. If a pipeline is "full" when a connection is to be reused, a new connection will be opened if the CURLMOPT_MAX_xxx_CONNECTIONS limits allow it. If not, the handle will be put in a pending state until a connection is ready (either free or a pipe got shorter). CURLMOPT_CONTENT_LENGTH_PENALTY_SIZE - A pipelined connection will not be reused if it is currently processing a transfer with a content length that is larger than this. CURLMOPT_CHUNK_LENGTH_PENALTY_SIZE - A pipelined connection will not be reused if it is currently processing a chunk larger than this. CURLMOPT_PIPELINING_SITE_BL - A blacklist of hosts that don't allow pipelining. CURLMOPT_PIPELINING_SERVER_BL - A blacklist of server types that don't allow pipelining. See the curl_multi_setopt() man page for details.
2013-02-15 05:50:45 -05:00
lib2033_CPPFLAGS = $(AM_CPPFLAGS) -DUSE_PIPELINING
Reference in New Issue Copy Permalink