Skip to content

Conversation

dkoes
Copy link
Contributor

@dkoes dkoes commented Nov 18, 2019

Every cmake package I've used exports the location of the library as a
variable. Perhaps this is no longer considered best practice(?) but it
is certainly common and expected practice.

This addes an OpenBabel3_LIBRARY variable to the cmake config file which
is defined to be the generator expression $<TARGET_FILE:openbabel>

I could not figure out how to get the location of the library relative
OpenBabel3_INSTALL_PREFIX

Every cmake package I've used exports the location of the library as a
variable.  Perhaps this is no longer considered best practice(?) but it
is certainly common and expected practice.

This addes an OpenBabel3_LIBRARY variable to the cmake config file which
is defined to be $<TARGET_FILE:openbabel>

I could not figure out how to get the location of the library relative
OpenBabel3_INSTALL_PREFIX
@baoilleach
Copy link
Member

Seems like an oversight. Pinging @cryos to see whether he agrees.

@cryos
Copy link
Member

cryos commented Nov 20, 2019

Yes I think this is expected behavior too, we normally use the convention of plural for external variables, i.e. the library might be defined in OpenBabel3_LIBRARY, but the variable for the public interface would be OpenBabel3_LIBARIES which may have more things added in the future. Same with _INCLUDE_DIR being internal often, and INCLUDE_DIRS being external - may be the same, but the plural normally defines the interface to use from the outside.

@baoilleach
Copy link
Member

@dkoes Can you make the changes that @cryos suggests regarding OpenBabel3_LIBRARIES and undo the edit to openbabel-python.i.

As a matter of interest, how is this used by the consuming project? I can add something to the docs.

Also removed python.i change
@dkoes
Copy link
Contributor Author

dkoes commented Nov 26, 2019

Example usage

find_package( OpenBabel3 REQUIRED )
include_directories( ${OpenBabel3_INCLUDE_DIRS})
add_executable(myapp ${SOURCES})
target_link_libraries(myapp ${OpenBabel3_LIBRARIES})

If I was less intimidated by cmake, I would also attempt to implement concurrent building of python2 and python3 bindings...
And if I had more time I'd fix the maeparser build issue that has crept into master.

@ghutchis
Copy link
Member

IMHO, I think it's time to drop Python2:
https://python3statement.org

@ghutchis
Copy link
Member

I should be able to get the maeparser bit tomorrow.

@dkoes
Copy link
Contributor Author

dkoes commented Nov 26, 2019

IMHO, I think it's time to drop Python2:
https://python3statement.org

I am in favor of making python3 the default (although concurrent builds of 2 and 3 is probably the most user friendly).

@baoilleach baoilleach merged commit c6b00dc into openbabel:master Nov 27, 2019
@baoilleach
Copy link
Member

Merging. Let's talk about Python elsewhere if need be.

@jscott0 jscott0 mentioned this pull request Apr 9, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants