Date: Mon, 3 Nov 2008 15:12:34 -0700 From: "Steve Franks" <stevefranks@ieee.org> To: "Giorgos Keramidas" <keramida@ceid.upatras.gr> Cc: freebsd-hackers <freebsd-hackers@freebsd.org> Subject: Re: includes, configure, /usr/lib vs. /usr/local/lib, and linux coders Message-ID: <539c60b90811031412y35e2599cneca5912ada43b081@mail.gmail.com> In-Reply-To: <87r65vl9ur.fsf@kobe.laptop> References: <539c60b90810311123w2aa94b8akcd0a5d0fe791885a@mail.gmail.com> <Pine.GSO.4.64.0810311154030.16737@zeno.ucsd.edu> <539c60b90810311230i11460966la7ff35b0093642ec@mail.gmail.com> <87r65vl9ur.fsf@kobe.laptop>
next in thread | previous in thread | raw e-mail | index | archive | help
That's alot of good info. It should go in the porter's handbook, maybe... So, if I'm looking to make a port, which one of those people should I be acting as? Maintainer? That's FreeBSD-port-terminology you are using, correct? Steve On Sat, Nov 1, 2008 at 8:55 AM, Giorgos Keramidas <keramida@ceid.upatras.gr> wrote: > On Fri, 31 Oct 2008 12:30:46 -0700, "Steve Franks" <stevefranks@ieee.org> wrote: >> Let's backup. What's the 'right' way to get a bloody linux program >> that expects all it's headers in /usr/include to compile on freebsd >> where all the headers are in /usr/local/include? That's all I'm >> really asking. Specifically, it's looking for libusb & libftdi. If I >> just type gmake, it can't find it, but if I manually edit the >> Makefiles to add -I/usr/local/include, it can. Obviously, manually >> editing the makefiles is *not* the right way to fix it (plus it's >> driving me crazy). > > Then you run `configure' with the `right' environment: > > env CPPFLAGS='-I/usr/local/include' \ > LDFLAGS='-L/usr/local/lib' ./configure > > The `--includedir' and `--libdir' options are *not* meant to be useful > to the developer that uses the GNU build tools, but to the person who > compiles something for the target host. > > There are several types of people involved in the `release' of a full > program: > > * The maintainer, who uses `automake', `libtool' and `autoconf' to > write portable Makefiles and build tools. > > * The builder, who compiles the program with specific options. > > * The packager, who runs `make install' in the build tree, creates a > set of installed files, and then packages *some* of these files in > a packaging-specific format. > > These types of people commonly have different constraints in the way > they can tweak and twist the GNU build tools, to match their needs. > > 1. The _maintainer_ of the program is free to set up his environment to > include any `CPPFLAGS', `CFLAGS' or `LDFLAGS' they find useful. For > example, if they have an experimental third-party library installed > in a custom location they can use: > > export CPPFLAGS='-I/opt/foolib/include' LDFLAGS='-L/opt/foolib/lib' > ./configure --prefix='/var/tmp/myprog' > > This way `configure' will emit Makefiles that try to use the > third-party library from `/opt/foolib' instead of the system-default > location for header files and libraries. > > This may often be a lot easier than waiting until the necessary bits > are installed in the ``official'' places at development systems. > Developers who want to experiment with a new version of `libfoo', > i.e. to integrate it with the rest of a program, can use custom > `CPPFLAGS' and `LDFLAGS' while everyone else is merrily going along > with the ``standard'' version of the `libfoo' library. > > 2. The _builder_ may be constrained in the sets of options he can pass > to the `CFLAGS'. He is, after all, testing how a pristine, clean > version of the program can build in what is defined as the ``official > release'' environment. > > He may be allowed to tinker with include paths and library paths, but > it is often safer to wrap the build process in scripts and tools that > yield a repeatable, verifiable build process. This may preclude the > use of options like `-I/custom/hdr/path' and `-L/custom/lib/path'. > > The builder of a program may not be an actual person, but a cron job > or another automated process, i.e. a `nightly build' script that runs > a clean build in a pristine environment, verifies that it can all > complete without errors, and then emails one or more reports. > > When the builder _is_ a real person, he may be sharing roles with the > third type of person involved in the build life of a program that > uses the GNU build tools: the packaging person. > > 3. The _packager_ is someone who runs `make install', to produce the > final program distribution and then bundles parts of or even all the > files that are produced by the usual `install' target of GNU tools. > The installation of all the files may be done in the default > installation `prefix', but it may also be redirected to a staging > area by setting `DESTDIR' in the environment: > > mkdir /var/tmp/proto > env DESTDIR=/var/tmp/proto make install > > Depending on the type of the target system, and on particular needs > of the packaging person, there may be cases where certain files have > to be installed in a `non-standard' location, or in a location that > was not foreseen by the original maintainer. In that case, the > packager can use the `--libdir' and `--includedir' options to change > the final, installed location of the relevant bits. > > A typical example is the case of Solaris systems, where libraries may > be installed in `/usr/lib/64' for 64-bit architectures. When a > packager prepares installation images for these architectures, he can > build the program with: > > ./configure --prefix='/opt/foo' --libdir='$prefix/lib/64' > > All this is a pretty long-winded way of saying: > > The `--includedir' and `--libdir' options are not really something > that is meant to be a convenience option for the _maintainer_ of a > program,, the person who writes the code. They are meant to be > useful tools for the _packager_ of the program, the person who > builds and prepares the final, install-able images. > > If you are the maintainer, who writes the code of a program, and you > find yourself in a position where you need to use the `--libdir' and > the `--includedir' options, then YOU ARE DOING IT WRONG. > > and, as you have probably guessed by now: > > The Linux people of the original post are wrong. > > The GNU build tools are a relatively good set of tools to automate a lot > of the mundane details of setting up a build system. It is unfortunate > that many people who use them have absolutely no clue of what they are > using, and they think that slapping a bunch of copy-paste snippets from > Google searches in a `configure.in' script will magically turn any odd > mess into a clean release process. Alas, Linux newbies are very often > exactly _this_ sort of person :/ > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?539c60b90811031412y35e2599cneca5912ada43b081>