configure option --with-libzmq=PREFIX removed

[pijyoi]

commit 313714f seems to have removed the above option.
This prevents compilation against a non-system-installed copy of libzmq.

[jemc]

When this feature gets restored, we should make sure it make its way into zproject so that it doesn't go away again when we start using zproject to autogenerate the czmq build systems.

@pmienk can you take a look at this, since the commit is yours and you've been dealing with the autoconf stuff in zproject?

[pmienk]

Please note that when pkg-config is involved, the equivalent behavior is accomplished by extending PKG_CONFIG_PATH with the path containing libzmq.pc. Given a versioned reference, this is the only mechanism in zproject to accomplish detection. Otherwise, zproject will fall back to processing a prefix provided in this manner if PKG_CHECK_MODULES fails.

[jemc]

@pijyoi
Can you use pkg-config in your use case? Whatever solution we use for package detection in autoconf needs to work in the general case (that is, general for any dependency package) because the czmq build systems will "soon" be under the domain of zproject.

[pmienk]

@pijyoi , presumably the install for libzmq you are trying to use has a lib/pkgconfigdirectory. We'll call that <path> (note it ends in /lib/pkgconfig). When configuring czmq, PKG_CONFIG_PATH=<path> ./configure should accomplish your goal. Or if you are installing to the same prefix, the pkgconfigdir mentioned by @evoskuil may provide the same path augmentation.

[pijyoi]

Okay, the following invocation works for me:
PKG_CONFIG_PATH=$HOME/local/lib/pkgconfig ./configure --prefix=$HOME/local

The following doesn't work though:
./configure --with-pkgconfigdir=$HOME/local/lib/pkgconfig

[pijyoi]

Could not get mingw32 cross-compiling to work with the new syntax (where it used to work with the --with-libzmq syntax):
PKG_CONFIG_PATH=$HOME/mingw32/lib/pkgconfig ./configure --prefix=$HOME/mingw32 --host=i686-pc-mingw32

[sappo]

I do have mingw32 cross compiling. I can tell you more when I'm back at
work tomorrow morning.
Am 19.11.2014 22:31 schrieb "pijyoi" notifications@github.com:

Could not get mingw32 cross-compiling to work with the new syntax (where
it used to work with the --with-libzmq syntax):
PKG_CONFIG_PATH=$HOME/mingw32/lib/pkgconfig ./configure
--prefix=$HOME/mingw32 --host=i686-pc-mingw32

—
Reply to this email directly or view it on GitHub
#818 (comment).

[sappo]

@pijyoi you'll need to define a pkg-config path for your host, this works for me:

PKG_CONFIG_PATH_x86_64_w64_mingw32="~/workspace/zeromq/cross_x86_64/lib/pkgconfig" ./configure --host=x86_64-w64-mingw32 --prefix=~/workspace/zeromq/cross_x86_64

[evoskuil]

It looks like configure.ac is handling --with-pkgconfigdir=<path> properly, so this should work.

./configure --with-pkgconfigdir=$HOME/local/lib/pkgconfig

This technique seems preferable to the environment variable, as it should be more selective in that it would apply only to this one ./configure call.

[sappo]

@evoskuil thanks for the hint. The --with-pkgconfigdir option works. But the errors when executing make remain. See #819

[evoskuil]

Cool, i'd guess the compiler error is unrelated. Also @pmienk pointed out to me that these pkgconfigdir techniques are equivalent as long as the env var technique is executed on one line.

[sappo]

Okay, do you have any idea about the compiler error?

[evoskuil]

Some idea, I'll refer readers to that thread - #819

[pijyoi]

Following Kevin's tip of naming the environment variable according to the
target (e.g. PKG_CONFIG_PATH_i686_pc_mingw32), I can run configure
successfully for host build or for cross-compile.

However, I can't seem to get "--with-pkgconfigdir" to work for either case.
This option seems to me to be much preferable if only for avoiding the
ugliness of the name of environment variable.

On Thu, Nov 20, 2014 at 3:02 PM, Eric Voskuil notifications@github.com
wrote:

Cool, i'd guess the compiler error is unrelated. Also @pmienk
https://github.com/pmienk pointed out to me that these pkgconfigdir
techniques are equivalent as long as the env var option is executed on one
line.

Reply to this email directly or view it on GitHub
#818 (comment).