update: libxlsxwriter 1.2.4 with upstream directory structure

[billdenney]

Restructure vendored libxlsxwriter source to mirror the upstream distribution layout under src/libxlsxwriter/:
src/libxlsxwriter/src/ (was src/libxlsxwriter/)
src/libxlsxwriter/include/ (was src/include/)
src/libxlsxwriter/third_party/ (was src/md5/, src/minizip/, src/tmpfileplus/)

This makes future updates a simple copy of the src/, include/, and third_party/ directories from the upstream tarball. Update src/Makevars with the new paths and add src/libxlsxwriter/**/Makefile* to .gitignore so upstream Makefiles are not tracked (they trigger R CMD check warnings about GNU extensions and are not used by the R build).

[jeroen]

Be careful of adding extra files that we do not need (e.g. all the minizip stuff), because you will have to comply with licensing and declare copyright of everything included in the package, even if the files are not used at all.

[billdenney]

@jeroen, Thank you for that note/warning. I'll cull the parts that we're not using and add them to .gitignore.

[billdenney]

I changed the COPYRIGHT file to be a symlink to the libxlsxwriter license file so that we will remain constantly up to date. I think that as long as the R build process works with that (currently running), it should be a perpetual solution.

[jeroen]

That does not suffice for CRAN, they will grep for all files in the package with a line Copyright in the headers and then you have to name all those entities in the authors part of DESCRIPTION. It is really easier to not ship redundant stuff with the releases....

[jeroen]

Also symlinks do not work on all Windows systems...

[billdenney]

I verified that the symlink works as expected on my Windows computer. (git for Windows handles symlinks.)

In #101, I've fixed it so that there is a Copyright field similar to RcppEigen.

All of the current third-party included directories (after I removed dtoa) were in the previous release, so there is nothing new included as a separate third party, but there were additional files in that directory. I will resolve that momentarily.

[jeroen]

I verified that the symlink works as expected on my Windows computer. (git for Windows handles symlinks.)

IIRC, problems would appear on Windows when extracting a tar.gz file that contains symlinks. So I think it's better to not put them into the R source package.

[billdenney]

I just verified that R CMD build dereferences symlinks automatically. So, it's not a symlink in the source package; it's a regular file. The reason I'd like to keep it is that a symlink automatically keeps us license-compliant and at least according to CRAN policies is compliant there, too.

[jeroen]

I just verified that R CMD build dereferences symlinks automatically. So, it's not a symlink in the source package; it's a regular file.

Okay I did not know that. According to the docs, the default for tar is to embed the symlink unless you pass the -h flag, but I do not see R doing that.