Re: pkg/44577 openssl builtin detection, getting closer

[John Marino <marino%netbsd.org@localhost>]

The following reply was made to PR pkg/44577; it has been noted by GNATS.

From: John Marino <marino%netbsd.org@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: pkg/44577 openssl builtin detection, getting closer
Date: Mon, 14 Nov 2011 07:45:06 +0100

 I need to clarify that this is happening with EVERY package that sucks 
 in the openssl buildlink3 (in the environments the issue is seen of 
 course).  It's only noticeable on those packages where openssl is 
 detected via pkgconfig.  The same thing is occurring on security/heimdal 
 for example, but it doesn't use the faulty openssl.pc file.
 
 The "included twice" theory is a pretty good one, but I still have the 
 questions:
 1) Why not use C header still defines to ignore re-included makefiles?
 2) What's the problem with redefining BUILTIN_PKG.openssl?  That implies 
 it's sacred, but the rest of the files can be redefined (albeit 
 erroneously) e.g. BUILTIN_VERSION.openssl.
 3) I'm not sure how your trick is going to help.  I'm able to detect the 
 case that it's redefined already.
 
 I'm testing with "> bmake -V '${BUILTIN_VERSION.openssl}'" after the "> 
 bmake wrapper" phase.  There's no echoes with that, so I'm not seeing 
 how warnings are going to help?
 
 Looking closer, it seems that half the makefile is blocked off:
 
 ###
 ### The section below only applies if we are not including this file
 ### solely to determine whether a built-in implementation exists.
 ###
 CHECK_BUILTIN.openssl?=        no
 .if !empty(CHECK_BUILTIN.openssl:M[nN][oO])
 
 That would imply the openssl file would get created on the first pass   
 I don't see anywhere else CHECK_BUILTIN.openssl is defined.
 
  From what I can tell, there's no problem with just removing ".if 
 !defined(BUILTIN_PKG.openssl) && \".  Is the original author of this 
 builtin.mk file around, can we ask him?
 
 John