Building Bonmin 1.8 fails with Visual Studio 2017

[tkralphs]

I'm encountering a failure building Bonmin 1.8 with the Visual Studio compiler and I can trace the reason, I just can't figure out how it was ever possible to build it in the past, as this issue is long-standing. The problem is related to the same one we've patched libtool for in the past. The func_extract_an_archive doesn't work properly in Windows, both because of line endings and (as I now realize) directory separators. In a nutshell, libtool uses lib -nologo -list to find out what files are in a library. libtool pipes this into xargs echo to get rid of the carriage returns, but this fails because of line endings, so our patch also pipes it through dos2unix. But in Bonmin, the libraries are built from files that live in subdirectories and so we get

$ lib -nologo -list libbonalgorithms.lib
BonBabSetupBase.obj
BonBonminSetup.obj
BonSubMipSolver.obj
BonCbcLpStrategy.obj
BonSolverHelp.obj
.libs\libbonalgorithms.lax\libbonbranching.lib\BonChooseVariable.obj
.libs\libbonalgorithms.lax\libbonbranching.lib\BonLpBranchingSolver.obj
.libs\libbonalgorithms.lax\libbonbranching.lib\BonPseudoCosts.obj
.libs\libbonalgorithms.lax\libbonbranching.lib\BonQpBranchingSolver.obj
.libs\libbonalgorithms.lax\libbonbranching.lib\BonRandomChoice.obj
.libs\libbonalgorithms.lax\libbonoagenerators.lib\BonDummyHeuristic.obj
.libs\libbonalgorithms.lax\libbonoagenerators.lib\BonEcpCuts.obj
.libs\libbonalgorithms.lax\libbonoagenerators.lib\BonFpForMinlp.obj
.libs\libbonalgorithms.lax\libbonoagenerators.lib\BonOACutGenerator2.obj
.libs\libbonalgorithms.lax\libbonoagenerators.lib\BonOaDecBase.obj
.libs\libbonalgorithms.lax\libbonoagenerators.lib\BonOaFeasChecker.obj
.libs\libbonalgorithms.lax\libbonoagenerators.lib\BonOAMessages.obj
.libs\libbonalgorithms.lax\libbonoagenerators.lib\BonOaNlpOptim.obj
.libs\libbonalgorithms.lax\libbonquadcuts.lib\BonLinearCutsGenerator.obj
.libs\libbonalgorithms.lax\libbonquadcuts.lib\BonOuterApprox.obj
.libs\libbonalgorithms.lax\libbonquadcuts.lib\BonQuadCut.obj
.libs\libbonalgorithms.lax\libbonquadcuts.lib\BonQuadRow.obj
.libs\libbonalgorithms.lax\libbonquadcuts.lib\BonTMatrix.obj
.libs\libbonalgorithms.lax\libbonquadcuts.lib\BonTMINLP2Quad.obj
.libs\libbonalgorithms.lax\libbonquadcuts.lib\BonTMINLPLinObj.obj

When we pipe this through dos2unix and then xargs echo, the \ characters get removed and we end up with

$ lib -nologo -list /home/tkral/Projects/build-msvc2017/Bonmin/1.8/src/CbcBonmin/../Algorithms/.libs/libbonalgorithms.lib | dos2unix | xargs echo
BonBabSetupBase.obj BonBonminSetup.obj BonSubMipSolver.obj BonCbcLpStrategy.obj BonSolverHelp.obj .libslibbonalgorithms.laxlibbonbranching.libBonChooseVariable.obj .libslibbonalgorithms.laxlibbonbranching.libBonLpBranchingSolver.obj .libslibbonalgorithms.laxlibbonbranching.libBonPseudoCosts.obj .libslibbonalgorithms.laxlibbonbranching.libBonQpBranchingSolver.obj .libslibbonalgorithms.laxlibbonbranching.libBonRandomChoice.obj .libslibbonalgorithms.laxlibbonoagenerators.libBonDummyHeuristic.obj .libslibbonalgorithms.laxlibbonoagenerators.libBonEcpCuts.obj
.libslibbonalgorithms.laxlibbonoagenerators.libBonFpForMinlp.obj .libslibbonalgorithms.laxlibbonoagenerators.libBonOACutGenerator2.obj .libslibbonalgorithms.laxlibbonoagenerators.libBonOaDecBase.obj .libslibbonalgorithms.laxlibbonoagenerators.libBonOaFeasChecker.obj .libslibbonalgorithms.laxlibbonoagenerators.libBonOAMessages.obj .libslibbonalgorithms.laxlibbonoagenerators.libBonOaNlpOptim.obj .libslibbonalgorithms.laxlibbonquadcuts.libBonLinearCutsGenerator.obj .libslibbonalgorithms.laxlibbonquadcuts.libBonOuterApprox.obj .libslibbonalgorithms.laxlibbonquadcuts.libBonQuadCut.obj .libslibbonalgorithms.laxlibbonquadcuts.libBonQuadRow.obj .libslibbonalgorithms.laxlibbonquadcuts.libBonTMatrix.obj .libslibbonalgorithms.laxlibbonquadcuts.libBonTMINLP2Quad.obj .libslibbonalgorithms.laxlibbonquadcuts.libBonTMINLPLinObj.obj

and the later extraction of the object files from the library then fails. I'm just totally perplexed by how this can be coming up now. I spent many hours/days tracking down and patching the error with line endings, which affects Cgl and I'm certain I've built Bonmin successfully since then. @svigerske can you help me regain my sanity? I don't really want to patch the patch, given that this is now an old version of Bonmin and we will soon be making new release (I dearly hope). But I do want to leave it in a condition where it's building, just in case.

[svigerske]

Hmm, thought about it for a while, but nothing really came to my mind why that should have worked before or what has changed recently.

It could play a role that this is a noinst lib (?):

noinst_LTLIBRARIES = libbonalgorithms.la

I think that is uncommon and it should be easy to patch up Bonmin to avoid this, i.e., don't do

libbonalgorithms_la_LIBADD = Branching/libbonbranching.la
libbonalgorithms_la_LIBADD += OaGenerators/libbonoagenerators.la 
libbonalgorithms_la_LIBADD += QuadCuts/libbonquadcuts.la 

but add these libs directly to

libbonmin_la_LIBADD = \
	../Algorithms/libbonalgorithms.la \
	../Interfaces/libbonmininterfaces.la \
	Heuristics/libbonheuristics.la \
	$(BONMINLIB_LFLAGS)

[tkralphs]

Thanks, yeah, it always struck me as strange that we make a library, only to add it to another library.

I finally concluded that the problem must be due to a difference in how lib behaves under Visual Studio 2015 and Visual Studio 2017. I had previously only built locally with up to Visual Studio 2015 because the version of ifort I was using only worked with that version or earlier. Now I upgraded ifort and therefore Visual Studio as well. Everything seems to work fine with Visual Studio 2015. I will check, but I guess that the 2015 version of lib reports only the filename and not the relative path with lib -list.

I guess I will try to make the change you suggest, but I don't want to put a huge effort into this (obviously).

[tkralphs]

Ugh, so the final answer is that in Visual Studio 2015, the directory separator in the output of lib is the Unix one / and in Visual Studio 2017, they switched to the Windows one \! What a PITA!