[zeromq-dev] [PATCH] libzmq - includedir and broken VPATH builds
lukes at wetafx.co.nz
Tue Nov 15 11:54:09 CET 2011
I am receptive to this point, actually. OpenEXR originally had the same
arrangement, for example.
In saying this, I do believe they're moving their header into a
directory as part of the transition to version 2.0.
Maybe this change in the layout could similarly be part of the 3.x or
See the fact is that at our scale we'd never configure packages to
become a part of the platform, we'd do things more like
./configure --prefix=/mnt/this/that/zeromq-3.0.2/ --includedir=/mnt/this/that/zeromq-3.0.2/include(/zmq)
anyways, so that each client application can choose what version to use.
It's the inspection of files that start with 30-40 lines of includes
that makes it easier if all the include lines are "namespaced" with a
Please don't interpret this as me trying to push the direction in a way
or another, it was mostly to show a situation you may not have considered.
On 15/11/11 11:27 PM, Mikko Koppanen wrote:
> On Tue, Nov 15, 2011 at 9:56 AM, Luca Fascione<lukes at wetafx.co.nz> wrote:
>> Also, note that if you have a header a.h inside zmq/ you can slightly
>> alter the CPPFLAGS and the files that say #include<a.h> still work
>> fine, whereas the opposite is quite a bit harder :-)
> while moving the headers into their own sub-directories is nicer from
> packaging point of view I would be hesitant to implement this in
> stable releases.
> While this change is easy to implement for experienced C and C++
> developers we do have large amount of user's that struggle compiling
> the guide examples. Applying this change would force them to use the
> -I flag / not being able to compile the examples in a way that they
> have used to.
> Also, this would potentially break large amount of builds that rely on
> the header being deployed to the default include path.
> You should be able to achieve the same result by packaging your local copy with:
> ./configure --prefix=/usr --includedir=/usr/include/zmq
More information about the zeromq-dev