--with-binpac

This doesn't seem to work on the configure script. I have a separate binpac that I want use and it still builds and runs the one in the tree.

  .Seth

This doesn't seem to work on the configure script. I have a separate
binpac that I want use and it still builds and runs the one in the
tree.

Try this patch (to bro):

$ git diff
diff --git a/CMakeLists.txt b/CMakeLists.txt
index 005c5ae..e048305 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -77,7 +77,8 @@ FindRequiredPackage(PCAP)
FindRequiredPackage(OpenSSL)
FindRequiredPackage(BIND)

-if (EXISTS \{CMAKE\_CURRENT\_SOURCE\_DIR\}/aux/binpac/CMakeLists\.txt\) \+if \(NOT BinPAC\_ROOT\_DIR AND \+ EXISTS {CMAKE_CURRENT_SOURCE_DIR}/aux/binpac/CMakeLists.txt)
     add_subdirectory(aux/binpac)
endif ()
FindRequiredPackage(BinPAC)

That worked! Thanks.

One weird side effect is that if I do "make clean", and reconfigure without --with-binpac it still uses my separate out-of-tree binpac. I don't know if that matters or not, but it seems a little weird.

  .Seth

One weird side effect is that if I do "make clean", and reconfigure
without --with-binpac it still uses my separate out-of-tree binpac. I
don't know if that matters or not, but it seems a little weird.

--with-binpac will set BinPAC_ROOT_DIR in the CMakeCache.txt and "make clean" doesn't get rid of it.

At the moment I'm not sure if this behavior is going to be easily changed because it's actually a lot more pervasive than just --with-binpac. I think this occurs at least with the way most dependency libraries/headers will be found as well as some of the configure checks. It's probably also partly a downside to using a configure wrapper; I think using one of the standard cmake front-ends would allow you to directly set/unset any variable. You could also directly edit the cache, if you want.

I thought I remember from my experiences with Autotools-based software, that it's usually recommended to do a distclean if you're going to be reconfiguring w/ significantly different choices? So translating that to CMake, I'd recommend starting from a new build directory (not necessarily deleting the original one; see the --builddir option). Is that cool w/ everyone?

- Jon

I thought I remember from my experiences with Autotools-based software, that it's usually recommended to do a distclean if you're going to be reconfiguring w/ significantly different choices? So translating that to CMake, I'd recommend starting from a new build directory (not necessarily deleting the original one; see the --builddir option). Is that cool w/ everyone?

The configure wrapper could maybe issue a warning if it is run as a
reconfigure (i.e., if it's run and builddir already exists....)

cu
gregor

That might be nice. It would at least be a good reminder when I (inevitably) do this in the future.

  .Seth

Could the configure wrapper just decline to configure with a
different set of options than last time (plus some advice on how to
solve the problem)? Now that we have config.status, we already
remember what was used before.

Robin

Could the configure wrapper just decline to configure with a
different set of options than last time (plus some advice on how to
solve the problem)? Now that we have config.status, we already
remember what was used before.

I was also thinking this approach would be good. I'll wait to see if there's more comments, though.

- Jon

> Could the configure wrapper just decline to configure with a
> different set of options than last time (plus some advice on how to
> solve the problem)? Now that we have config.status, we already
> remember what was used before.

I was also thinking this approach would be good. I'll wait to see if
there's more comments, though.

Thought of solution that I think is best: on each invocation, the configure wrapper can just delete an existing CMakeCache.txt before calling cmake (no need for displaying warnings to user about anything).

This makes each ./configure independent from previous ones.

- Jon

Makes sense.

Robin

Sounds good to me.

  .Seth