coin-or / CppAD

A C++ Algorithmic Differentiation Package: Home Page
https://cppad.readthedocs.io
Other
446 stars 94 forks source link

SPEED_DIRS: Command not found when compiling under MSYS/MS cl #25

Closed devosgit closed 3 years ago

devosgit commented 6 years ago

I am attempting to build COIN-OS from the latest trunk version. During the make step, the following error results: Making all in cppad make[1]: Entering directory /c/coin-os/5287.1/cppad' cp cppad/configure.hpp ../../cppad/cppad/configure.hpp SPEED_DIRS = make[1]: SPEED_DIRS: Command not found make[1]: *** [../../cppad/cppad/configure.hpp] Error 127 make[1]: Leaving directory/c/coin-os/5287.1/cppad' make: *** [all-recursive] Error 1

Do you have any idea what would cause this error and what the fix would be? (make.log and config.log for cppad are attached.) make 1-4-18 141pm.log config-cppad.log

tkralphs commented 3 years ago

Yes, that warning always pops up and has for many years with cl. I think if you use the latest libtool, it may take care of it, but it can be safely ignored.

You still haven't added ar-lib to your repo, so from a clean checkout, the same errors arise. You also didn't fix the error that arises when not adding --enable-msvc (things should still work in this case). But if I add ar-lib manually and also use the argument --enable-msvc, then things look OK until I hit the compiler error

C:\msys64\home\tkral\Projects\cppad\cppad_lib\json_lexer.cpp(224): error C2039: 'isdigit': is not a member of 'std'

This is a known problem with older versions of cl (I believe I'm using Visual Studio 2015 for my testing). If you want to remain compatible with some older (but not that old) versions of cl, which I would recommend, you should fix those issues.

bradbell commented 3 years ago

If you go to https://www.gnu.org/software/automake/manual/automake.html#Auxiliary-Programs There is a reference to ar-lib and above it says `all of these files are distributed and installed with Automake'

So I should be able to get this file through pacman ?

tkralphs commented 3 years ago

I don't think so. There are a number of auxiliary programs that are distributed as part of the autotools and that need to be included in the source distribution of any software that uses the autotools, but since those programs are not generally invoked directly by users, they would not be installable using a package manager. That is why I pointed out where ar-lib is included in Cbc, as an example. There are others as well, like config.sub, config.guess, install-sh that play a similar role, but you already added those at some point. You probably just forgot. Anyway, you can just copy ar-lib from Cbc if you want. How are you getting so far without it, though?

bradbell commented 3 years ago

I will try putting ar-lib in the top source directory.

It seems to me that ar-lib is similar to config.sub and the autotools distribute config.sub with the package but not ar-lib ?

bradbell commented 3 years ago

I now see what is going on. I have a local copy of config.sub in the repository, but ar-lib is a link:


cppad.git>ls -l ar-lib
lrwxrwxrwx. 1 bradbell bradbell 31 Sep 29 06:22 ar-lib -> /usr/share/automake-1.16/ar-lib

cppad.git>ls -l config.sub
-rwxr-xr-x. 1 bradbell bradbell 31428 Oct 21 17:25 config.sub

cppad.git>ls -l /usr/share/automake-1.16/config.sub
-rwxr-xr-x. 1 root root 31428 Jul 24  2019 /usr/share/automake-1.16/config.sub

``
bradbell commented 3 years ago

I added ar-lib to the top source directory, but it still trys to use g++ when I build without the --enable-msvc flag.

tkralphs commented 3 years ago

In the case without --enable-msvc, configure is still finding cl and is setting that as the C++ compiler, so it's not a problem with configure setting the wrong compiler. There must be a mistake somewhere in your setup that causes the use of g++. I can look for it myself if you are not able to find it, but I guess a little grepping will turn it up. By the way, --enable-msvc is a custom flag, not an autotools flag. It is the flag we use to indicate that the compiler search order should be changed to prioritize the microsoft compiler, but it shouldn't have any effects beyond that.

bradbell commented 3 years ago

I have looked and do not know what is causing it to use g++ when it says it cannot find g++. Any help in this regard would be welcome. In addition, after I execute

../configure --enable-msvc CXX_FLAGS='EHsc'
make test

Many of the tests pass until I get to the error

... snip ...
vec_unary.obj
LINK : fatal error LNK1181: cannot open input file '..\..\cppad_lib.obj'
make[1]: *** [makefile:682: general.exe] Error 2
make[1]: Leaving directory '/home/bradl/repo/cppad.git/build/test_more/general'
make: *** [makefile:909: check-am] Error 2

You can run make test in the build/test_more/general directory and get this message without building and running the other tests. I do not know what automake is expecting in test_more/general/makefile.am so that this library gets found ?

bradbell commented 3 years ago

I had to do some fixing of the cmake build due to this issue: https://discourse.cmake.org/t/on-windows-check-cxx-source-runs-is-calling-check-source-runs/2065

Install cmake for win64-x64; see https://cmake.org/download/ make sure you select the box that adds cmake to your execution path.

The following can now be used to build and check cppad on windows:

rm -r build
mkdir build
cd build
cmake -G "NMake Makefiles" -D debug_which="debug_all" ..
nmake check
bradbell commented 3 years ago

It is unfortunate that the version of cmake installed by pacman does not support the NMake Makefiles generator option, it used to support it. I had to changed my install instructions for Visual Studio because of this change to pacman.

I have posted an issue about this at https://github.com/msys2/MINGW-packages/issues/7175

bradbell commented 3 years ago

As it turns out, Visual Studio 2019 includes a version of cmake that generates NMake Makefiles at /c/Program Files (x86)/Microsoft Visual Studio/2019/Community/Common7/IDE/CommonExtensions/Microsoft/CMake/CMake/bin/cmake

As mentioned in https://github.com/msys2/MINGW-packages/issues/7175 one can also use pacman -S mingw-w64-x86_64-cmake to get a version that generates NMake Makefiles.

tkralphs commented 3 years ago

This problems seems to be fixed now in master! It would be great if there could be a release that includes the fixes. There is another separate issue related to generation of the pkgconfig file that I will open another issue or pull request for. Thanks!

bradbell commented 3 years ago

I will create a 20210000 release on the first of next year.

devosgit commented 3 years ago

Wow! That is great news. Awesome effort by the two of you.

Thank you!

On Wed, Dec 16, 2020, 2:05 PM Brad Bell notifications@github.com wrote:

I will create a 20210000 release on the first of next year.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/coin-or/CppAD/issues/25#issuecomment-746931287, or unsubscribe https://github.com/notifications/unsubscribe-auth/AC5GAYUEWCHHIUGT5F2K6GDSVEHJZANCNFSM4EKSHDCA .