-
Notifications
You must be signed in to change notification settings - Fork 98
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Interface fixes and enhancements #154
base: master
Are you sure you want to change the base?
Conversation
…rror C2039: 'ReturnType': is not a member of 'Eigen::ScalarBinaryOpTraits...'
- now simplified usage of cppad via find_package and target_link_libraries in depending projects is possible - fixed: problems if pkgconfig can not be used - fixed: linking error (not finding definition of local::temp_file) - using more generic header install directory
It seems that three things are going on here:
|
Just for eigen changes (item 3 above): For this case, I think you can add your test by modifying the following file: |
I have merged pull request 155 (which corresponds to item 3 above). Would you please remove the corresponding parts of this pull request, so that it only implements item 1 above. |
# Conflicts (fixed): # test_more/general/cppad_eigen.cpp
The package config file installed by Eigen is |
Yes, you are probably right here. However, when using Eigen via pure Cmake (see |
|
It's simply a boolean cache variable, "off" by default. It switches between using "pkgconfig" / "cmake" for linking to external projects. This can probably be implemented a little bit more consistent, but I didn't dive that deep into the present cmake/pkgconfig machinery of Cppad. |
Are you trying to accomplish something that is not supported by the current CppAD cmake command ? If so, can you provide a workflow in |
It seems this
I am sorry, but at this point I have to step back a little for capacity reasons... But as mentioned above the concrete failings without this pull request are the following (commit 90aca75):
Besides, the transitive dependencies commit 6e4a74b is certainly not fixing anything, but rather a feature. |
Yes, when an optional package has a pkgconfig file, CppAD expects to be able to use that file and instead of providing the install information for the package on the command line, it just uses a true/false flag on the command line and gets the necessary information from pkgconfig. Is there a system you have using that does not have access to pkgconfig ? If so, this is a problem for all the true/false optional package flags on the CppAD cmake command line. |
Yes, indeed, this the case. In my case Eigen sufficient. |
What system are you using (that does not have pkgconfig) ? |
Windows. |
Are you using microsoft development tools, minsys, or cygwin ? |
If any, the first. |
I have been trying to get a msys system to build using github workflows (as a demonstration of how to do this). But have run into difficulities because the generated executables are not found; see the workflow branch |
@guestieng and then just using
Make sure this works for you before we go onto adding eigen. |
Thank you very much for your help and effort. |
@guestieng do not understand. Do you have a google or other id that we could chat over. My google id is bradley.m.bell. If you send a chat id to that address (in next hour or so) I will accept it. |
I think I have solved the problem of building the tests, including the eigen tests, on windows using the Visual C++ compiler. See the following workflow file: Here is an example workflow output: This required a change to the CppAD cmake API; see the heading 07-16 on Does this work for you ? |
If you would like more support for installing without pkg-config, I suggest that we start with the use-case of eigen on windows.
to execute a different macro in cmake/findpackage_info.cmake that checks for eigen using If both fail, then report the fatal error that the install failed. |
The following problems have been fixed:
(now, by depending projects, very simple usage of cppad via
find_package(cppad <...>)
andtarget_link_libraries(<...> cppad <...>)
is possible)Moreover, more support for depending projects can be provided now via transitive dependencies (cmake/cppadConfig.cmake.in)