Hi Kay,
On Thu, Jun 23, 2016 at 07:03:19PM +0200, Kay Fuchs wrote:
> Hi list,
>
> i'm on the latest 1.6 version(a7b7ad0d75) and i'm used to compile HAProxy like
>
> make TARGET=linux2628 USE_PCRE=1 USE_LINUX_SPLICE=1 USE_LINUX_TPROXY=1
> USE_GETADDRINFO=1 USE_OPENSSL=1 SSL_INC=$staticlibssl/include
> SSL_LIB=$staticlibssl/lib USE_SLZ=1 SLZ_INC=$libslz/src
> SLZ_LIB=$libslz
>
> and if all went well make install. But since "BUILD/MEDIUM: rebuild
> everything when an include file is changed" and "BUILD/MEDIUM: force a
> full rebuild if some build options change" make install compiles some
> more files, although the binary is allready compiled. The compiled
> binary seems not to be ready. For example it doesn't understand the
> keyword "ssl" in the bind line.
>
> If i compile and install in one go like
>
> make TARGET=linux2628 USE_PCRE=1 USE_LINUX_SPLICE=1 USE_LINUX_TPROXY=1
> USE_GETADDRINFO=1 USE_OPENSSL=1 SSL_INC=$staticlibssl/include
> SSL_LIB=$staticlibssl/lib USE_SLZ=1 SLZ_INC=$libslz/src
> SLZ_LIB=$libslz install
>
> all is well.
So now I understand what's happening. It's interesting because the only
reason it used to work is precisely due to the lack of controls. The
"make install" target depends on "haproxy", so it is supposed to be
called with exactly the same options. For example if you would run
"make" with certain options and it fails, then run "make install", it
would have caused a build of the failed files with different options
resulting in something odd.
I'm seeing two options :
1) perform a check in the "install" target to force all the same
options to be passed again to "make install" as to "make". I find
this quite cumbersome and counter-intuitive for users, and is
often a pain to put into distro packages because these two
operations are performed at different places.
2) simply remove the dependency between "install" and anything else.
If "make install" is called before "make", it will simply fail as
do many other products in the same situation. If it is called after,
it will install what was previously built.
I'm willing to go for #2 now which is (in my opinion) the safest solution
and the least cumbersome for users. If people have problems with that
being done into 1.6, I can also revert the two patches that fix the build
dependencies, but I'd prefer to keep them to stop having to ask users to
perform a clean rebuild after each bug report.
For 1.7 I'm going for #2 right now anyway to address this issue for now.
Regards,
Willy
