Bug in src/Makefile

1 view
Skip to first unread message

Philip Prindeville

unread,
Dec 18, 2007, 10:38:12 PM12/18/07
to vim...@googlegroups.com
Haven't checked to see if this is fixed yet, but it's definitely present
in 7.1:

# "make install". An existing file will be overwritten!
# When not using it, some make programs can't handle an undefined $(LINKIT).
-LINKIT = -ln -f -s $(BINDIR)/$(VIMTARGET) /usr/bin/vi
+LINKIT = -ln -f -s $(DEST_BIN)/$(VIMTARGET) /usr/bin/vi
#LINKIT = @echo >/dev/null

###


Philip Prindeville

unread,
Dec 18, 2007, 10:47:01 PM12/18/07
to vim...@googlegroups.com

Hmm.... Actually, since it's invoked as:

-$(LINKIT)

we probably don't need the "-" in the definition of the macro expansion
(RHS), either.


Philip Prindeville

unread,
Dec 18, 2007, 11:29:29 PM12/18/07
to vim...@googlegroups.com
One more time, for the sake of the braindead (such as me):

How about:

ifeq ($(LINK_TO_VI),y)
LINKIT="ln -s -f"
else
LINKIT=":"
endif

...

-$(LINKIT) $(BINDIR)/$(VIMTARGET) $(DESTDIR)/usr/bin/vim

instead?

That way, you can do a "make install_normal LINK_TO_VI=y" without editing the Makefile.

While I'm at it, looking at src/configure.in:


have_local_include=''
have_local_lib=''
if test "$GCC" = yes; then
echo 'void f(){}' > conftest.c
dnl -no-cpp-precomp is needed for OS X 10.2 (Ben Fowler)
...
if test "$tt" = "$CPPFLAGS"; then
CPPFLAGS="$CPPFLAGS -I/usr/local/include"
fi
fi


Should that read:

have_local_include=''
have_local_lib=''
if test "$cross_compiling" = no; then
if test "$GCC" = yes; then
echo 'void f(){}' > conftest.c
dnl -no-cpp-precomp is needed for OS X 10.2 (Ben Fowler)
...
if test "$tt" = "$CPPFLAGS"; then
CPPFLAGS="$CPPFLAGS -I/usr/local/include"
fi
fi
fi


And lastly... why does the target "installrtbase" install the man pages?

How do I get an installation with everything but the man pages?

Thanks,

-Philip

Bram Moolenaar

unread,
Dec 19, 2007, 11:21:17 PM12/19/07
to Philip Prindeville, vim...@googlegroups.com

Philip Prindeville wrote:

Yes, that should work better when DESTDIR is set. I'll make that
change. Also removing the dash.

--
If VIM were a woman, I'd marry her. Slim, organized, helpful
and beautiful; what's not to like? --David A. Rogers

/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ download, build and distribute -- http://www.A-A-P.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

Bram Moolenaar

unread,
Dec 19, 2007, 11:21:17 PM12/19/07
to Philip Prindeville, vim...@googlegroups.com

Philip Prindeville wrote:

> One more time, for the sake of the braindead (such as me):
>
> How about:
>
> ifeq ($(LINK_TO_VI),y)
> LINKIT="ln -s -f"
> else
> LINKIT=":"
> endif
>
> ...
>
> -$(LINKIT) $(BINDIR)/$(VIMTARGET) $(DESTDIR)/usr/bin/vim
>
> instead?

What make understands "ifeq"? This looks restricted to some versions of
make.

How can LINKIT only be ":"?

> While I'm at it, looking at src/configure.in:
>
>
> have_local_include=''
> have_local_lib=''
> if test "$GCC" = yes; then
> echo 'void f(){}' > conftest.c
> dnl -no-cpp-precomp is needed for OS X 10.2 (Ben Fowler)
> ...
> if test "$tt" = "$CPPFLAGS"; then
> CPPFLAGS="$CPPFLAGS -I/usr/local/include"
> fi
> fi
>
>
> Should that read:
>
> have_local_include=''
> have_local_lib=''
> if test "$cross_compiling" = no; then
> if test "$GCC" = yes; then
> echo 'void f(){}' > conftest.c
> dnl -no-cpp-precomp is needed for OS X 10.2 (Ben Fowler)
> ...
> if test "$tt" = "$CPPFLAGS"; then
> CPPFLAGS="$CPPFLAGS -I/usr/local/include"
> fi
> fi
> fi

That should be part of the cross-compiling patch then. The distributed
configure doesn't support cross compiling.

> And lastly... why does the target "installrtbase" install the man pages?
>
> How do I get an installation with everything but the man pages?

Run make on the other targets. It's fairly unusual not to install man
pages.

--
hundred-and-one symptoms of being an internet addict:
254. You wake up daily with your keyboard printed on your forehead.

Vladimir Marek

unread,
Dec 20, 2007, 4:04:43 AM12/20/07
to vim...@googlegroups.com
> > One more time, for the sake of the braindead (such as me):
> >
> > How about:
> >
> > ifeq ($(LINK_TO_VI),y)
> > LINKIT="ln -s -f"
> > else
> > LINKIT=":"
> > endif
> >
> > ...
> >
> > -$(LINKIT) $(BINDIR)/$(VIMTARGET) $(DESTDIR)/usr/bin/vim
> >
> > instead?
>
> What make understands "ifeq"? This looks restricted to some versions of
> make.

Correct, this is gnu make extension afaik. It can be constructed like
this however:

LINK_TO_VI = YES

LINKIT_YES = ln -s -f
LINKIT_NO = :
LINKIT = $(LINKIT_$(LINK_TO_VI))

Other possibility would be to solve this at automake/autoconf level,
adding new parameter to 'configure' script.

> How can LINKIT only be ":"?

: is shell builtin, try 'type :'. It just expands arguments and returns
true. (so that ': $(touch a)' creates file a). To be sure I checked it
for sh, bash and ksh on Solaris.

--
Vlad

Ben Schmidt

unread,
Dec 20, 2007, 10:32:37 AM12/20/07
to vim...@googlegroups.com
>> How can LINKIT only be ":"?
>
> : is shell builtin, try 'type :'. It just expands arguments and returns
> true. (so that ': $(touch a)' creates file a). To be sure I checked it
> for sh, bash and ksh on Solaris.

I would've thought the confusion wasn't over what ':' did, but over why, if you
can't link, you would do nothing rather than copy instead, or provide some other
kind of second-best mechanism that's...well...better than nothing.

Ben.

Send instant messages to your online friends http://au.messenger.yahoo.com

Philip Prindeville

unread,
Dec 25, 2007, 10:10:21 PM12/25/07
to vim...@googlegroups.com

Well, this is what I finally ended up using:

+--- vim71/src/Makefile.orig 2007-05-12 04:57:13.000000000 -0700
++++ vim71/src/Makefile 2007-12-18 23:39:14.000000000 -0800
+@@ -1074,8 +1074,10 @@
+ # default vi editor, it will create a link from vi to Vim when doing
+ # "make install". An existing file will be overwritten!
+ # When not using it, some make programs can't handle an undefined $(LINKIT).
+-#LINKIT = -ln -f -s $(BINDIR)/$(VIMTARGET) /usr/bin/vi
+-LINKIT = @echo >/dev/null
++LINKIT_n = @:
++LINKIT_ = $(LINKIT_n)
++LINKIT_y = ln -f -s
++LINKIT = $(LINKIT_$(LINK_TO_VI))
+
+ ###
+ ### GRAPHICAL USER INTERFACE (GUI). {{{1
+@@ -1761,7 +1764,7 @@
+ $(STRIP) $(DEST_BIN)/$(VIMTARGET)
+ chmod $(BINMOD) $(DEST_BIN)/$(VIMTARGET)
+ # may create a link to the new executable from /usr/bin/vi
+- -$(LINKIT)
++ -$(LINKIT) $(BINDIR)/$(VIMTARGET) $(DESTDIR)/usr/bin/vi
+
+ # Long list of arguments for the shell script that installs the manual pages
+ # for one language.


Can we get it reviewed, approved, and committed?

Thanks,

-Philip


Bram Moolenaar

unread,
Dec 29, 2007, 4:05:02 PM12/29/07
to Philip Prindeville, vim...@googlegroups.com

Philip Prindeville wrote:

I prefer having the LINKIT variable have the whole command, so that it
can be anything. Having it all in one line is a lot simpler. So I have
this now:

# If you are using Linux, you might want to use this to make vim the


# default vi editor, it will create a link from vi to Vim when doing

# "make install". An existing file will be overwritten!

# When not using it, some make programs can't handle an undefined $(LINKIT).

#LINKIT = ln -f -s $(DEST_BIN)/$(VIMTARGET) $(DESTDIR)/usr/bin/vi
LINKIT = @echo >/dev/null


--
He was not in the least bit scared to be mashed into a pulp
Or to have his eyes gouged out and his elbows broken;
To have his kneecaps split and his body burned away
And his limbs all hacked and mangled, brave Sir Robin.
"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

Tony Mechelynck

unread,
Dec 29, 2007, 4:39:26 PM12/29/07
to vim...@googlegroups.com, Philip Prindeville

Shouldn't the last argument to ln be either $(DEST_BIN)/vi (without /usr/bin)
or /usr/bin/vi (without $(DESTDIR)) ? I'm not sure creating a link with a name
of (let's say) /usr/local/usr/bin/vi would work.

Best regards,
Tony.
--
"I stayed up all night playing poker with tarot cards. I got a full
house and four people died."
-- Steven Wright

Bram Moolenaar

unread,
Dec 30, 2007, 9:29:56 AM12/30/07
to Tony Mechelynck, vim...@googlegroups.com, Philip Prindeville

Tony Mechelynck wrote:

$DESTDIR is the root directory of the installation. It's normally empty.
You can set it to "/tmp/myroot" to build in a shadow directory tree.
$prefix may be "/usr/local".

The idea of using "/usr/bin/vi" is that the "normal" vi links to the vim
command you just installed, possibly as /usr/local/bin/vim.

--
DINGO: And after the spanking ... the oral sex.
GALAHAD: Oh, dear! Well, I...
GIRLS: The oral sex ... The oral sex.
GALAHAD: Well, I suppose I could stay a BIT longer.

Tony Mechelynck

unread,
Dec 30, 2007, 10:44:17 AM12/30/07
to Bram Moolenaar, vim...@googlegroups.com, Philip Prindeville
Bram Moolenaar wrote:
[...]

> $DESTDIR is the root directory of the installation. It's normally empty.
> You can set it to "/tmp/myroot" to build in a shadow directory tree.
> $prefix may be "/usr/local".

ah, I thought $DESTDIR would normally be /usr/local. Sorry for "spamming the
bug" (as the Mozilla devs call it).

>
> The idea of using "/usr/bin/vi" is that the "normal" vi links to the vim
> command you just installed, possibly as /usr/local/bin/vim.
>

Best regards,
Tony.


--
hundred-and-one symptoms of being an internet addict:

200. You really believe in the concept of a "paperless" office.

Philip Prindeville

unread,
Jan 3, 2008, 2:26:09 PM1/3/08
to vim...@googlegroups.com

Well, same request applies:


LINKIT_y = ln -f -s $(DEST_BIN)/$(VIMTARGET) $(DESTDIR)/usr/bin/vi
LINKIT_n = @:
LINKIT_ = $(LINKIT_n)
LINKIT = $(LINKIT_$(LINK_TO_VI))


Can we do that instead? I'm trying to have a Makefile (and eventually
configure.in) that builds with the fewest numbers of patches applied.

We're trying to get it into AstLinux 0.5 trunk, but want to be able to
use it without having to apply any patches... since the way AstLinux is
built is by scripts that pull down source tarballs and then build them
according to prepackaged directions. Updating version numbers is a lot
easier than updating patches...

Thanks,

-Philip


Bram Moolenaar

unread,
Jan 3, 2008, 4:19:39 PM1/3/08
to Philip Prindeville, vim...@googlegroups.com

Philip Prindeville wrote:

This syntax looks invalid, using () inside (). Another GNU make thing?

> Can we do that instead? I'm trying to have a Makefile (and eventually
> configure.in) that builds with the fewest numbers of patches applied.
>
> We're trying to get it into AstLinux 0.5 trunk, but want to be able to
> use it without having to apply any patches... since the way AstLinux is
> built is by scripts that pull down source tarballs and then build them
> according to prepackaged directions. Updating version numbers is a lot
> easier than updating patches...

If you are making an install script, you are probably much better off
when you create the link in the install script. Then you can also keep
track of what has been created. Depending on your installer, of course.

--
Have you heard about the new Barbie doll? It's called Divorce
Barbie. It comes with all of Ken's stuff.

Vladimir Marek

unread,
Jan 3, 2008, 5:53:27 PM1/3/08
to vim...@googlegroups.com
> > LINKIT_y = ln -f -s $(DEST_BIN)/$(VIMTARGET) $(DESTDIR)/usr/bin/vi
> > LINKIT_n = @:
> > LINKIT_ = $(LINKIT_n)
> > LINKIT = $(LINKIT_$(LINK_TO_VI))
>
> This syntax looks invalid, using () inside (). Another GNU make thing?

I tried this using the Solaris make and it works.

=============================== Makefile ===============================
SELECT=N
OPTION_Y=YES
OPTION_N=NO

all:
@echo $(OPTION_$(SELECT))
========================================================================

$ make
NO
$ make SELECT=Y
YES

--
Vlad

Philip Prindeville

unread,
Jan 3, 2008, 7:30:10 PM1/3/08
to vim...@googlegroups.com

I'm not aware of any versions of Make that don't support it... Except
the make that comes with Visual C++.


>> Can we do that instead? I'm trying to have a Makefile (and eventually
>> configure.in) that builds with the fewest numbers of patches applied.
>>
>> We're trying to get it into AstLinux 0.5 trunk, but want to be able to
>> use it without having to apply any patches... since the way AstLinux is
>> built is by scripts that pull down source tarballs and then build them
>> according to prepackaged directions. Updating version numbers is a lot
>> easier than updating patches...
>>
>
> If you are making an install script, you are probably much better off
> when you create the link in the install script. Then you can also keep
> track of what has been created. Depending on your installer, of course.
>
>

I'll go back and look at it.

What about the changes that I and Tony submitted for cross-compilation?

-Philip


Reply all
Reply to author
Forward
0 new messages