[Packaging] Avoid bundling static libraries in Windows conda packages

[asfimport]

We're currently bundling static libraries in Windows conda packages. Unfortunately, it causes these to be quite large:

$ ls -la ./Library/lib
total 507808
drwxrwxr-x 4 antoine antoine      4096 avril  3 10:28 .
drwxrwxr-x 5 antoine antoine      4096 avril  3 10:28 ..
-rw-rw-r-- 1 antoine antoine   1507048 avril  1 20:58 arrow.lib
-rw-rw-r-- 1 antoine antoine     76184 avril  1 20:59 arrow_python.lib
-rw-rw-r-- 1 antoine antoine  61323846 avril  1 21:00 arrow_python_static.lib
-rw-rw-r-- 1 antoine antoine 328090000 avril  1 21:02 arrow_static.lib
drwxrwxr-x 3 antoine antoine      4096 avril  3 10:28 cmake
-rw-rw-r-- 1 antoine antoine    491292 avril  1 21:02 parquet.lib
-rw-rw-r-- 1 antoine antoine 128473780 avril  1 21:03 parquet_static.lib
drwxrwxr-x 2 antoine antoine      4096 avril  3 10:27 pkgconfig

(see files in https://anaconda.org/conda-forge/arrow-cpp/files )

We should probably only ship dynamic libraries under Windows, as those are reasonably small.

Reporter: Antoine Pitrou / @pitrou
Assignee: Krisztian Szucs / @kszucs

_{Note: This issue was originally created as ARROW-5101. Please see the migration documentation for further details.}

[asfimport]

Krisztian Szucs / @kszucs:
The windows builds are quiet confusing. It seems like conda-forge has shipped windows packages with appveyor builds, but there are failing azure pipelines builds as well: https://github.com/conda-forge/arrow-cpp-feedstock/runs/90277892

If We're going to separate the static libraries into another package (arrow-cpp-static), then We shouldn't build static libraries for unix neither.

[asfimport]

Krisztian Szucs / @kszucs:
The solution would be to use multiple outputs as described in conda-forge/libprotobuf-feedstock#24

[asfimport]

Antoine Pitrou / @pitrou:
Static libraries are probably used much more often on Unix than on Windows, where DLLs are the norm. So it makes sense to still ship static libraries on Unix if it doesn't pose a problem.

[asfimport]

Uwe Korn / @xhochy:
I would actually vote for only distributing dynamic libs on all platforms in conda packages. This seems to be the default for mostly all conda packages and the preferred way of Linux distributions. We have mostly added static libraries in our dependencies in conda-forge in the beginning of Arrow development as Arrow wanted to have static libs. 

[asfimport]

Krisztian Szucs / @kszucs:
Agree with Uwe.

[asfimport]

Wes McKinney / @wesm:
@kszucs can you address this for 0.15.0?

[asfimport]

Krisztian Szucs / @kszucs:
This should have been resolved by conda-forge/arrow-cpp-feedstock@d6e21db already

@pitrou could you check with version 0.14?

[asfimport]

Wes McKinney / @wesm:
@kszucs can you check? Do you have a Windows VM?

[asfimport]

Antoine Pitrou / @pitrou:
I confirm that the arrow-cpp-0.14.1 size is very reasonable on Windows (10.6 MB download, ~34 MB on disk).

[asfimport]

Antoine Pitrou / @pitrou:
Fixed by conda-forge/arrow-cpp-feedstock#79

[asfimport]

Krisztian Szucs / @kszucs:
The archives here https://conda-static.anaconda.org/conda-forge/win-64/ does not contain the static libs:

Library/bin
├── arrow.dll
├── arrow_dataset.dll
├── arrow_flight.dll
├── arrow_python.dll
├── gandiva.dll
└── parquet.dll
Library/lib
├── arrow.lib
├── arrow_dataset.lib
├── arrow_flight.lib
├── arrow_python.lib
├── cmake
│ └── arrow
│ ├── arrowConfig.cmake
│ ├── arrowConfigVersion.cmake
│ ├── arrowTargets-release.cmake
│ └── arrowTargets.cmake
├── gandiva.lib
├── parquet.lib
└── pkgconfig
├── arrow-compute.pc
├── arrow-dataset.pc
├── arrow-flight.pc
├── arrow-python.pc
├── arrow.pc
├── gandiva.pc
└── parquet.pc