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

345 lines
10 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 \
lib560 lib562 lib564 lib565 lib566 lib567 lib568 lib569 lib570 \
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 \
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
lib1509 lib1510 \
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
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
lib556_SOURCES = lib556.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
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)
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
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