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

compile vim7 with different or without local prefix /usr/local

Expand Messages
  • Michael Haubenwallner
    Hi, maybe I ve overlooked something in configure.in, but to me it seems that it is impossible to compile vim7 without searching /usr/local/include and
    Message 1 of 4 , Dec 18, 2006
      Hi,

      maybe I've overlooked something in configure.in, but to me it seems that
      it is impossible to compile vim7 without searching /usr/local/include
      and /usr/local/lib.

      Thing is, on solaris fex, if iconv.h is found in /usr/local/include,
      /usr/local/lib/libiconv.so get linked too.
      But the rpath for libiconv.so.3 does not get encoded into the binary,
      and I really don't want to set LD_LIBRARY_PATH (hmm, maybe this should
      be in system loader path).

      Additionally, I also want to be able to compile completely independent
      of /usr/local, with a gcc built --with-local-prefix=/another/prefix, and
      with libiconv and others from that prefix.

      So I have two new requirements for the /usr/local search:

      1) Of course, I want to keep the default as is.
      2) completely disable adding /usr/local/include and /usr/local/lib
      3) set a different path to be used instead of /usr/local

      Attached is a patch for src/configure.in to accept "--with-local-prefix"
      flag, which solves above requirements:

      1) default: do not pass any --with-local-prefix argument.
      2) disable: use --without-local-prefix or even --with-local-prefix=no
      3) change: use --with-local-prefix=/another/prefix

      Thanks,
      haubi
      --
      Michael Haubenwallner SALOMON Automation GmbH
      Forschung & Entwicklung A-8114 Friesach bei Graz
      mailto:michael.haubenwallner@... http://www.salomon.at
      No HTML/MIME please, see http://expita.com/nomime.html
    • Bram Moolenaar
      ... It make sense to support using another directory than /usr/local/[lib|include]. It appears that after your patch have_local_include and have_local_lib are
      Message 2 of 4 , Jan 8, 2007
        Michael Haubenwallner wrote:

        > maybe I've overlooked something in configure.in, but to me it seems that
        > it is impossible to compile vim7 without searching /usr/local/include
        > and /usr/local/lib.
        >
        > Thing is, on solaris fex, if iconv.h is found in /usr/local/include,
        > /usr/local/lib/libiconv.so get linked too.
        > But the rpath for libiconv.so.3 does not get encoded into the binary,
        > and I really don't want to set LD_LIBRARY_PATH (hmm, maybe this should
        > be in system loader path).
        >
        > Additionally, I also want to be able to compile completely independent
        > of /usr/local, with a gcc built --with-local-prefix=/another/prefix, and
        > with libiconv and others from that prefix.
        >
        > So I have two new requirements for the /usr/local search:
        >
        > 1) Of course, I want to keep the default as is.
        > 2) completely disable adding /usr/local/include and /usr/local/lib
        > 3) set a different path to be used instead of /usr/local
        >
        > Attached is a patch for src/configure.in to accept "--with-local-prefix"
        > flag, which solves above requirements:
        >
        > 1) default: do not pass any --with-local-prefix argument.
        > 2) disable: use --without-local-prefix or even --with-local-prefix=no
        > 3) change: use --with-local-prefix=/another/prefix

        It make sense to support using another directory than
        /usr/local/[lib|include].

        It appears that after your patch have_local_include and have_local_lib
        are set to "yes" without checking gcc. The test for gcc with "grep"
        should also use ${local_prefix} instead of /usr/local.

        I'm missing documentation, especially for the "no" value.

        --
        If someone questions your market projections, simply point out that your
        target market is "People who are nuts" and "People who will buy any damn
        thing". Nobody is going to tell you there aren't enough of those people
        to go around.
        (Scott Adams - The Dilbert principle)

        /// Bram Moolenaar -- Bram@... -- 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 ///
      • Michael Haubenwallner
        ... Well, they are set to yes in the --without-local-prefix or --with-local-prefix=no case only to avoid appending to CPPFLAGS/ LDFLAGS lateron (they are
        Message 3 of 4 , Jan 8, 2007
          On Mon, 2007-01-08 at 22:16 +0100, Bram Moolenaar wrote:
          > Michael Haubenwallner wrote:
          >
          > > maybe I've overlooked something in configure.in, but to me it seems that
          > > it is impossible to compile vim7 without searching /usr/local/include
          > > and /usr/local/lib.
          > >
          > > Thing is, on solaris fex, if iconv.h is found in /usr/local/include,
          > > /usr/local/lib/libiconv.so get linked too.
          > > But the rpath for libiconv.so.3 does not get encoded into the binary,
          > > and I really don't want to set LD_LIBRARY_PATH (hmm, maybe this should
          > > be in system loader path).
          > >
          > > Additionally, I also want to be able to compile completely independent
          > > of /usr/local, with a gcc built --with-local-prefix=/another/prefix, and
          > > with libiconv and others from that prefix.
          > >
          > > So I have two new requirements for the /usr/local search:
          > >
          > > 1) Of course, I want to keep the default as is.
          > > 2) completely disable adding /usr/local/include and /usr/local/lib
          > > 3) set a different path to be used instead of /usr/local
          > >
          > > Attached is a patch for src/configure.in to accept "--with-local-prefix"
          > > flag, which solves above requirements:
          > >
          > > 1) default: do not pass any --with-local-prefix argument.
          > > 2) disable: use --without-local-prefix or even --with-local-prefix=no
          > > 3) change: use --with-local-prefix=/another/prefix
          >
          > It make sense to support using another directory than
          > /usr/local/[lib|include].
          >
          > It appears that after your patch have_local_include and have_local_lib
          > are set to "yes" without checking gcc. The test for gcc with "grep"
          > should also use ${local_prefix} instead of /usr/local.

          Well, they are set to "yes" in the "--without-local-prefix" or
          "--with-local-prefix=no" case only to avoid appending to CPPFLAGS/
          LDFLAGS lateron (they are not used any more in configure script).

          The grep-test on gcc only applies if there is no "--with-local-prefix"
          argument on configure line at all, to use the defaults.

          Well, if one explicitly specifies "--with-local-prefix" on configure-
          cmdline, I'm unsure if the compiler should be checked if it already
          searches that path.

          Hmm, thinking more of it, it makes sense, as the compiler could be
          confused when explicitly passing its builtin search dirs...

          >
          > I'm missing documentation, especially for the "no" value.

          I don't know how to type two lines of documentation into the autoconf-
          macro to keep some good alignment in the help-output, but maybe this
          text could appear:
          --with-local-prefix=/prefix build against /prefix instead of /usr/local
          --without-local-prefix do not build against any additional prefix

          Thank you (especially for accepting the idea behind),
          haubi
        • Bram Moolenaar
          ... I thought the idea of this configure argument was that you specify another place than /usr/local, one that the compiler might already look in. Anyway, I
          Message 4 of 4 , Jan 9, 2007
            Michael Haubenwallner wrote:

            > > > maybe I've overlooked something in configure.in, but to me it seems that
            > > > it is impossible to compile vim7 without searching /usr/local/include
            > > > and /usr/local/lib.
            > > >
            > > > Thing is, on solaris fex, if iconv.h is found in /usr/local/include,
            > > > /usr/local/lib/libiconv.so get linked too.
            > > > But the rpath for libiconv.so.3 does not get encoded into the binary,
            > > > and I really don't want to set LD_LIBRARY_PATH (hmm, maybe this should
            > > > be in system loader path).
            > > >
            > > > Additionally, I also want to be able to compile completely independent
            > > > of /usr/local, with a gcc built --with-local-prefix=/another/prefix, and
            > > > with libiconv and others from that prefix.
            > > >
            > > > So I have two new requirements for the /usr/local search:
            > > >
            > > > 1) Of course, I want to keep the default as is.
            > > > 2) completely disable adding /usr/local/include and /usr/local/lib
            > > > 3) set a different path to be used instead of /usr/local
            > > >
            > > > Attached is a patch for src/configure.in to accept "--with-local-prefix"
            > > > flag, which solves above requirements:
            > > >
            > > > 1) default: do not pass any --with-local-prefix argument.
            > > > 2) disable: use --without-local-prefix or even --with-local-prefix=no
            > > > 3) change: use --with-local-prefix=/another/prefix
            > >
            > > It make sense to support using another directory than
            > > /usr/local/[lib|include].
            > >
            > > It appears that after your patch have_local_include and have_local_lib
            > > are set to "yes" without checking gcc. The test for gcc with "grep"
            > > should also use ${local_prefix} instead of /usr/local.
            >
            > Well, they are set to "yes" in the "--without-local-prefix" or
            > "--with-local-prefix=no" case only to avoid appending to CPPFLAGS/
            > LDFLAGS lateron (they are not used any more in configure script).
            >
            > The grep-test on gcc only applies if there is no "--with-local-prefix"
            > argument on configure line at all, to use the defaults.
            >
            > Well, if one explicitly specifies "--with-local-prefix" on configure-
            > cmdline, I'm unsure if the compiler should be checked if it already
            > searches that path.
            >
            > Hmm, thinking more of it, it makes sense, as the compiler could be
            > confused when explicitly passing its builtin search dirs...

            I thought the idea of this configure argument was that you specify
            another place than /usr/local, one that the compiler might already look
            in. Anyway, I think the behavior shouldn't change, only the path used.

            > > I'm missing documentation, especially for the "no" value.
            >
            > I don't know how to type two lines of documentation into the autoconf-
            > macro to keep some good alignment in the help-output, but maybe this
            > text could appear:
            > --with-local-prefix=/prefix build against /prefix instead of /usr/local
            > --without-local-prefix do not build against any additional prefix

            Unusual configure options should be documented in src/INSTALL, in the
            Unix section.

            --
            hundred-and-one symptoms of being an internet addict:
            2. You kiss your girlfriend's home page.

            /// Bram Moolenaar -- Bram@... -- 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 ///
          Your message has been successfully submitted and would be delivered to recipients shortly.