Re: building devel/bmake on case-insensitive filesystems

[Brook Milligan <brook%nmsu.edu@localhost>]

> On Aug 12, 2017, at 6:02 PM, Simon J. Gerraty <sjg%juniper.net@localhost> wrote:
> 
> Brook Milligan <brook%nmsu.edu@localhost> wrote:
> 
>> I have long had trouble with devel/bmake not defining MAKE_VERSION on MacOS, and have finally figured out why.  Among the files in devel/bmake/files are the following:
>> 
>> - Makefile: this defines MAKE_VERSION, which must be kept in sync with the version in devel/bmake/Makefile
> 
> I would assume  devel/bmake/Makefile could get the value from
> devel/bmake/files/Makefile ?

Indeed, it could.  That is not currently how it works, though.

>> - makefile.in: this is converted to makefile by configure, and does not define MAKE_VERSION.
> 
> Yes, but the generated makefile should be in a different directory than
> $srcdir where Makefile and make-bootstrap.sh.in are.
> 
> So the case insensitve fs should not matter?

The original files are in devel/bmake/files, but are all copied to ${WRKSRC}, which is where configure places the generated makefile.  That process overwrites Makefile in a case-insensitive filesystem.

>> On a case-insenstivie filesystem, of course, Makefile and makefile are
>> the same thing.  Consequently, configure overwrites Makefile with
>> makefile (which does not define MAKE_VERSION), so make-bootstrap.sh
>> injects an empty string for MAKE_VERSION into the bmake binary.
> 
> I haven't ever used devel/bmake but surely it builds in a separate work
> dir ?

Yes, it does.  Everything is built in ${WRKSRC}.  But, the contents of ${WRKSRC} include (after configure is run) both Makefile and makefile.  These of course collide for a case-insensitive filesystem.  That is the fundamental problem that needs solving.

>> As far as I can tell, neither Makefile nor makefile (from makefile.in)
>> are used during the build process other than to extract MAKE_VERSION
>> from the former.
> 
> makefile.in exists for those folk who refuse to read instructions and
> demand that just
> 
> ./configure
> make
> 
> works
> 
> Makefile exists for those (like me) who just do bmake -f Makefile
> to build next version.

This implies that 'bmake -f Makefile' and 'bmake -f makefile’ will accomplish the same thing, although the former uses a real Makefile while the latter actually runs boot-strap.  Does there really need to be two different ways of accomplishing the same thing?

>> I see several possible solutions that will solve this problem:
>> 
>> - Change configure (and configure.in) so that makefile is not created from makefile.in.  This leaves the original Makefile (with MAkE_VERSION) in place for make-bootstrap.sh to extract MAKE_VERSION.
> 
> The point of makefile.in is that if makefile is generated it takes
> precedence over Makefile.
> So the above would break more than it fixes.
> 
> First though how is generated makefile in the same directory as Makefile
> when using pkgsrc ?

As described earlier, both Makefile and makefile.in are copied into ${WRKSRC}.  Consequently, configure creates makefile from makefile.in and puts it into the same directory, which overwrites Makefile on a case-insensitive filesystem.

To support case-insensitive filesystems, there cannot be both Makefile and makefile.  Neither are actually used by the pkgsrc build system (it uses make-bootstrap.sh) except for defining the value of MAKE_VERSION.

If both Makefile and makefile.in are crucial to maintain separately within the bmake distribution, then the fix must be limited to how bmake is imported into pkgsrc.

Cheers,
Brook