Loading ...
Sorry, an error occurred while loading the content.

Re: dependency for configure in Makefile

Expand Messages
  • Bram Moolenaar
    ... I have always wondered what is so special about configure that people don t run it from the Makefile, like everything else. The recommended way for Vim is
    Message 1 of 2 , Oct 30, 2002
      Zvi Har'El wrote:

      > VIM's main Makefile has the dependency of $(VIMTARGET) on
      > auto/config.mk and auto/config.mk on auto/config.mk on config.h.in.
      > This implies whenever we receive a patch for configure.in, as was done
      > in patch 247, trying to run make will run the rule for auto/config.mk,
      > which is running configure. This is bad: As it happened for me, I ran,
      > after doing the patch, "./configure --with-features=big", and then ran
      > "make". Make ran configure again, this time without the
      > "--with-features" parameter, and the results is that I got a normal
      > version of vim, not the big version. I needed to run configure and
      > make again to get the big version. Unfortunately this happens quite
      > often, and until I noticed that configure is being run without my
      > knowledge, I was buffled why I get the wrong version!

      I have always wondered what is so special about configure that people
      don't run it from the Makefile, like everything else. The recommended
      way for Vim is to uncomment a few lines in the Makefile and then run
      "make". No need to write a shell script to remember the configure

      Running configure separately still works, but (as you noticed) after
      patching something may work wrong. The best solution is to do "make
      distclean" after patching. You never know what was patched, thus
      starting with a clean set of files is always a good idea.

      > I have another problem with the patches for configure.in: Inside these
      > patches, we always have a patch for auto/configure. However, the
      > Makefile has a dependancy of auto/configure on configure.in, and on
      > some machine, such as solaris, this forces running the related rule,
      > i.e., to run autoconf. I stumbled on that in the past when I had a
      > non-compatible version of autoconf (too new..., since than I
      > downgraded autoconf ;-). But know I fell on another pithole related to
      > that: Since I don't insert all the patches together, but insert each
      > patch as it arrives, my configure file is not the one generated by the
      > previous patch, but the file generated by autoconf, which is not
      > guaranteed to be identical to the file the person who prepared the
      > patch had. As a result, Patching vim with 6.1.247 failed. I removed
      > everything, untarred the sources and reapplied all the patches to the
      > clean source. It worked. Only later I realized that what I should have
      > done is to ignore the failure, remove auto/configure, and do make
      > again (this is my analysis - I didn't really try this). I am not sure
      > how to solve the situation - perhaps you autoconf gurus out there have
      > a suggestion...

      The best solution is to never run autoconf. There are incompatible
      versions around. Unfortunately, "make" easily gets confused when both
      configure.in and auto/configure are patched. Which one will be the
      newest is unpredictable. I don't know a solution to this, other than
      doing "touch auto/configure" after patches. Perhaps I should remove the
      rule to run autoconf, because only people who change configure.in need
      it, and they can do "make autoconf".

      Be nice to your kids... they'll be the ones choosing your nursing home.

      /// Bram Moolenaar -- Bram@... -- http://www.moolenaar.net \\\
      /// Creator of Vim - Vi IMproved -- http://www.vim.org \\\
      \\\ Project leader for A-A-P -- http://www.a-a-p.org ///
      \\\ Lord Of The Rings helps Uganda - http://iccf-holland.org/lotr.html ///
    Your message has been successfully submitted and would be delivered to recipients shortly.