CODEWITHSUNDEEP
linuxinstallationautotoolsconfigureautoconf
cli2
cli2

Reputation: 249

Unable to run configure file if not in the same directory

I am unable to run the configure file for a manual tar.gz package install. For example, after unzipping my file, I run

$ sudo ./vim81/configure
[sudo] password for cli2:
./vim81/configure: line 6: cd: src: No such file or directory

However, if I am inside the directory where the configure file exists, I am able to run the configure file.

$ ./configure
configure: loading cache auto/config.cache
checking whether make sets $(MAKE)... yes
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
...

My question is how do I execute the configure file if I am not at the same directory as the source file?

I know I can use yum or apt-get to install vim, but is just an example package and I want to do this manually for any package. Thanks.

Upvotes: 0

Views: 7027

Answers (1)

John Bollinger
John Bollinger

Reputation: 181849

I know I can use yum or apt-get to install vim, but is just an example package and I want to do this manually for any package.

There is no sure-fire universal recipe for building from source, even if you limit the scope to just Autotools-based packages (which evidently Vim is not, exactly). This is among the reasons why software packaging, package repositories, and package managers have become so widespread.

As someone who has performed a lot of package building, I assure you that it is a rare joy when I run into a project that I can package up via the equivalent of a straight-up configure; make; make install. When I meet one, it makes my day. The rest of the time, I have to figure out any number of build details on a per-package basis, such as

  • which configuration / build system, if any, is in use
    • Autotools / CMake / Python setuptools / etc.
    • This affects the build / install commands needed, and details such as what working directory can / should be used for the build
  • which configuration options are needed or appropriate for the target machine(s), and how to express them to the build system
    • can be options to a configure script, arguments to make, manual tweaks to a Makefile, answers to an interactive questionaire, ...
  • what dependencies are required, at what versions, and how to get them if I don't already have them
  • sometimes, how to clean up post-installation, for example,
    • to remove files I didn't want installed
    • to move files that went to the wrong place (despite best available use of build configuration)
    • to fix file permissions or ownership
  • sometimes, additional installation tasks, such as
    • adding shell-configuration files
    • creating symlinks
    • enrolling services with the system's service-control subsystem
    • installing dynamic linker configuration files

All of that applies at least as much to manual builds, too. If you do not rely on someone else to do that (i.e. by using packages built by someone else) then you need to be prepared to do yourself as many of those things as are required for each project you build. There is no way to automate it from that starting point.

Upvotes: 1

Related Questions