From owner-freebsd-doc@FreeBSD.ORG Fri Oct 25 22:38:34 2013 Return-Path: Delivered-To: freebsd-doc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 0ADEFD26 for ; Fri, 25 Oct 2013 22:38:34 +0000 (UTC) (envelope-from kuuse.redantigua@gmail.com) Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 88E3E279C for ; Fri, 25 Oct 2013 22:38:33 +0000 (UTC) Received: by mail-la0-f52.google.com with SMTP id eh20so3611853lab.11 for ; Fri, 25 Oct 2013 15:38:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=Ld5TiZGgusenK9SwzjJ9t/mFLtRt1MxjF2/HBAnarRU=; b=RL56cdnXEhc+AIrPWBeNNxoj2ftUM8BlIPlJp1wXaMRDwu/YRcy6g371mjiOUrl0Gk 3+yb//styoCh/83JF1q2e6CX/Po1g8u+m7+gRNFiL4BjBU+bipn5FOZP3qoBJwHCc76J s6qSyI418eO5U0kjvJTIqj4W1kNdesaPZyux+EtIsvvhRHsHZbyOvEeoI0LbcqHGy/Vv UlRpZIjUgqCUkkxI0Zb3Kl03w+HAj6fqjjK4S0SzOKNEHH/PT3U2WbvCx9jdjlwgeLs2 Z9uNtlMt8IAFMzqh9CACABazDCIsjcEbqRmbyQYb9IxrAfw66lYK3k5oK6KkHdYizcEH jFVQ== MIME-Version: 1.0 X-Received: by 10.112.72.100 with SMTP id c4mr6714lbv.57.1382740711646; Fri, 25 Oct 2013 15:38:31 -0700 (PDT) Sender: kuuse.redantigua@gmail.com Received: by 10.114.201.101 with HTTP; Fri, 25 Oct 2013 15:38:31 -0700 (PDT) In-Reply-To: <20131025174720.870B35807E@chaos.jnpr.net> References: <20131024214923.CB0AF5807E@chaos.jnpr.net> <20131025174720.870B35807E@chaos.jnpr.net> Date: Sat, 26 Oct 2013 00:38:31 +0200 X-Google-Sender-Auth: YSObSWAOETkFli4yQ0t9jLBGK7w Message-ID: Subject: Re: FreeBSD Make question From: Johan Kuuse To: "Simon J. Gerraty" Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-doc@freebsd.org X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 22:38:34 -0000 Johan: Sorry for cluttering up my last mail with "enhanced" Gmail RTF, here we go again in plain text, and a couple of added comments. Benjamin: >>>Simon: do we allow whitespace in target names in either fmake or bmake? >>>If so, what are the escaping rules? Johan: > Thanks Benjamin for the hints, I'll check out the -hackers list. Simon: > Whether it is "allowed" or not, it isn't something I would consider >doing. Johan: >Hi Simon, >I definitely agree that whitespaces shouldn't go into targets if it could be avoided. Simon: >>This works fine - my dirdeps.mk uses absolute paths of directories (plus >>added attributes) as targets Johan: >The background is that I'm trying to create a system of nonrecursive Makefiles, where all paths must be absolute. >This implies using absolute paths as target names. What if a path contains whitespaces? (God forbid!) Simon: You lose. Ideally you throw an error. .error "Sorry ${USER}, I cannot let you do that" Alternatively you could try substituting the spaces with glob chars. That may cause more trouble than it fixes. fixing make to handle this would not be trivial. Johan: Can you give an example of such a (glob chars) substitution? May it be similar to, or better than, my ugly hack (see below)? Simon: >What is the problem we are trying to solve? Johan: Problem described above, below goes a sample Makefile, trying several ways to escaping whitespaces in target names. The Makefile: Makefile.freebsd-questions -------- # MY_TARGET=/home/joe/directory name with spaces/hello.c # MY_SECOND_TARGET=/home/joe/directory name with spaces/world.c # MY_TARGET='/home/joe/directory name with spaces/hello.c' # MY_SECOND_TARGET='/home/joe/directory name with spaces/world.c' # MY_TARGET="/home/joe/directory name with spaces/hello.c" # MY_SECOND_TARGET="/home/joe/directory name with spaces/world.c" MY_TARGET=/home/joe/directory\ name\ with\ spaces/hello.c MY_SECOND_TARGET=/home/joe/directory\ name\ with\ spaces/world.c all: ${MY_TARGET} ${MY_SECOND_TARGET} @echo This is Make version $(MAKE_VERSION) ${MY_TARGET}: @echo $@ ${MY_SECOND_TARGET}: @echo $@ -------- The output: FreeBSD Make fails: make -f Makefile.freebsd-questions -------- "Makefile.freebsd-questions", line 20: warning: duplicate script for target "/home/joe/directory\" ignored "Makefile.freebsd-questions", line 20: warning: duplicate script for target "name\" ignored "Makefile.freebsd-questions", line 20: warning: duplicate script for target "with\" ignored /home/joe/directory\ name\ with\ spaces/hello.c spaces/world.c This is Make version 9201120530 -------- GNU Make works OK: gmake -f Makefile.freebsd-questions -------- /home/joe/directory name with spaces/hello.c /home/joe/directory name with spaces/world.c This is Make version 3.82 -------- The only possible workaround I have found so far with FreeBSD Make, is to substitute whitespaces with another character in the target variables, for example '+', (i.e. /home/joe/directory+name+with+spaces/hello.c) and using the modified variable as the target name. In the target rule, the variable substitution then has to be "reversed" to obtain the "real" target name: # MY_TARGET=/home/joe/directory name with spaces/hello.c # MY_TARGET_PLUS != echo "$(MY_TARGET)" | sed -e 's/ /+/g' ${MY_TARGET_PLUS}: @echo "${@:C/\+/ /g}" Using this ugly hack, the warnings disappears in the example above, but it doesn't really resolve the problem, as MY_TARGET_PLUS will always be a non-existing target. So using this hack, targets will always be executed/rebuilt, even if MY_TARGET is up to date. Please just confirm that there is no other, better glob char substitution, to resolve this problem. Then I can consider FreeBSD Make + target-name-with-whitespaces = dead end. Best regards, Johan Kuuse