maketgz creates release tarballs and removes the -DEV string in curl
version (e.g. 7.58.0-DEV), else -DEV shows up on command line when curl
is run. maketgz works fine on linux but fails on OSX. Problem is with
the sed commands that use option -i without an extension. Maketgz
expects GNU sed instead of BSD and this simply won't work on OSX. Adding
a backup extension .bak after -i fixes this issue
Running the script as if on OSX gives this error:
sed: -e: No such file or directory
Adding a .bak extension resolves it
Closes#2660
The compressed output size seems to be a tad bit smaller, but generally
xz seems more preferred these days and is used directly by for example
gentoo instead of bz2.
"Users of LZMA Utils should move to XZ Utils" =>
https://tukaani.org/lzma/Closes#1604
The maketgz script now makes sure the generated hugehelp.c file in the
tarball is newer than the generated curl.1 man page, so that it doesn't
have to get unnecessarily rebuilt first thing in a typical build. It
thus also removes the need for perl to build off a plain release
tarball.
Fixes#1565
... and support and additional "security patched" date for those who
enhance older versions that way. Pass on the define CURL_PATCHSTAMP with
a date for that.
Building with non-release headers shows the date as [unreleased].
Also: this changes the date format generated in the curlver.h file to be
"YYYY-MM-DD" (no name of the day or month, no time, no time zone) to
make it easier on the eye and easier to parse. Example (new) date
string: 2017-05-09
Suggested-by: Brian Childs
Closes#1474
maketgz now runs scripts/updatemanpages.pl to update the man pages .TH
section to use the current date and curl/libcurl version.
(TODO Section 3.1)
Closes#1058
I use the curl repo mainly on Windows with the typical Windows git
checkout which converts the LF line endings in the curl repo to CRLF
automatically on checkout. The automatic conversion is not done on files
in the repo with mixed line endings. I recently noticed some weird
output with projects/build-openssl.bat that I traced back to mixed line
endings, so I scanned the repo and there are files (excluding the
test data) that have mixed line endings.
I used this command below to do the scan. Unfortunately it's not as easy
as git grep, at least not on Windows. This gets the names of all the
files in the repo's HEAD, gets each of those files raw from HEAD, checks
for mixed line endings of both LF and CRLF, and prints the name if
mixed. I excluded path tests/data/test* because those can have mixed
line endings if I understand correctly.
for f in `git ls-tree --name-only --full-tree -r HEAD`;
do if [ -n "${f##tests/data/test*}" ];
then git show "HEAD:$f" | \
perl -0777 -ne 'exit 1 if /([^\r]\n.*\r\n)|(\r\n.*[^\r]\n)/';
if [ $? -ne 0 ];
then echo "$f";
fi;
fi;
done
Apparently the previous usage didn't work with that implementation,
while this updated version works with at least both Parallel BZIP2
v1.1.8 and regular bzip "Version 1.0.6, 6-Sept-2010".
Configuration files such as curl_config.h and all config-*.h no longer exist
nor are generated/copied into 'src' directory, now these only exist in 'lib'
directory from where curl tool sources uses them.
Additionally old src/setup.h has been refactored into src/tool_setup.h which
now pulls lib/setup.h
The possibility of a makefile needing an include path adjustment exists.
building with VC8 to get the "manifest" embedded to make fine stand-alone
binaries. The maketgz and the src/Makefile.vc6 files were adjusted
accordingly.
makefiles that are included in the source release archives, generated from
the Makefile.vc6 files by the maketgz script. I also modified the root
Makefile to have a VC variable that defaults to vc6 but can be overridden to
allow it to be used for vc8 as well. Like this:
nmake VC=vc8 vc
reported, the define is used by the configure script and is assumed to use
the 0xYYXXZZ format. This made "curl-config --vernum" fail in the 7.15.0
release version.
