Re: includes, configure, /usr/lib vs. /usr/local/lib, and linux coders
On Mon, 3 Nov 2008 15:12:34 -0700, Steve Franks [EMAIL PROTECTED] wrote: That's alot of good info. It should go in the porter's handbook, maybe... Hi Steve, Probably not. What I wrote is specific to the GNU build system. We have many ports that use configure scripts and makefiles generated from various versions of the GNU build tools, but ports are ``different''. We are not the _maintainers_ of the main source code of all the ported applications. We just have to make sure they build on FreeBSD, and that's pretty much all of it. For example, if the source tree of a port includes a `configure.in' that is broken on FreeBSD and Cygwin, we don't really have to ``fix'' both of these. If it builds correctly on FreeBSD, we are done. This may not be enough for Cygwin users, but we are not out to fix everyone's code to build on everybody else's system. That would be an insane amount of work for a very doubtful amount of gain :) 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? FreeBSD Porters are a separate category. They usually fall in the category of `builder' I mentioned in the original post, but they have to provide the tools for `packagers' too, in the form of Makefiles, scripts and packaging lists that allow others to configure, build and package the ``vendor'' code for some FreeBSD version. When I mentioned `maintainer', `builder' and `packager' roles in the original post I didn't mean *FreeBSD-maintainer* but the actual person or team that maintains the upstream source of a program. HTH, Giorgos ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: includes, configure, /usr/lib vs. /usr/local/lib, and linux coders
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 [EMAIL PROTECTED] wrote: On Fri, 31 Oct 2008 12:30:46 -0700, Steve Franks [EMAIL PROTECTED] 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
Re: includes, configure, /usr/lib vs. /usr/local/lib, and linux coders
On Fri, 31 Oct 2008 12:30:46 -0700, Steve Franks [EMAIL PROTECTED] 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
includes, configure, /usr/lib vs. /usr/local/lib, and linux coders
I believe someone has told me on this list that the proper way to compile a linux program is to run configure --includedir=/usr/local/include --libdir=/usr/local/lib. Is that correct? I've got a bunch of linux weenies trying to tell me their code isn't broken because I'm supposed to have headers where theirs are. They state that includedir is used by *their* project to locate it's *own* headers, so they never bothered to wire it up in Makefile.init gets ignored entirely. I figured I'd better know what I'm talking about before I tell someone they are 'wrong'. Especially as it's usually me ;) Steve ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: includes, configure, /usr/lib vs. /usr/local/lib, and linux coders
On Fri, Oct 31, 2008 at 12:11 PM, Nate Eldredge [EMAIL PROTECTED] wrote: On Fri, 31 Oct 2008, Steve Franks wrote: I believe someone has told me on this list that the proper way to compile a linux program is to run configure --includedir=/usr/local/include --libdir=/usr/local/lib. Nitpick: not specifically a Linux program, but a program using a configure script generated by GNU's autoconf system. Programs using autoconf may run on systems other than Linux (usually do, in fact, since the point of autoconf is portability), and many Linux programs don't use autoconf. And I'll assume that by 'linux' you actually mean FreeBSD, in order for this to be on-topic for this list :) Is that correct? I've got a bunch of linux weenies trying to tell me their code isn't broken because I'm supposed to have headers where theirs are. I don't understand this sentence. They state that includedir is used by *their* project to locate it's *own* headers, so they never bothered to wire it up in Makefile.init gets ignored entirely. I figured I'd better know what I'm talking about before I tell someone they are 'wrong'. Especially as it's usually me ;) It looks to me like both of you are wrong. :) Looking at the configure that comes with wget-1.11.2, running configure --help says Fine tuning of the installation directories: ... --libdir=DIR object code libraries [EPREFIX/lib] --includedir=DIR C header files [PREFIX/include] So it looks like --libdir is supposed to specify where libraries are to be *installed*, not where they are to be searched for. Further up in the help we have --prefix=PREFIX install architecture-independent files in PREFIX [/usr/local] --exec-prefix=EPREFIX install architecture-dependent files in EPREFIX [PREFIX] So libraries would already be installed in /usr/local/lib by default, unless you used a --prefix or --exec-prefix option to override that. Similarly for include files. If you need the program being built to search for libraries or include files in a certain place (such as /usr/local/include and /usr/local/lib, which are not searched by default on FreeBSD), AFAIK the right way to do it is to set the LIBRARY_PATH and C_INCLUDE_PATH (or CPLUS_INCLUDE_PATH) environment variables. -- Nate Eldredge [EMAIL PROTECTED] 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). Steve Steve ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: includes, configure, /usr/lib vs. /usr/local/lib, and linux coders
On Fri, 31 Oct 2008, Steve Franks 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). C_INCLUDE_PATH=$C_INCLUDE_PATH:/usr/local/include LIBRARY_PATH=$LIBRARY_PATH:/usr/local/lib export C_INCLUDE_PATH LIBRARY_PATH ./configure gmake Adjust as appropriate if using csh. Personally, I set those environment variables in my .profile. By the way, I think you're being a little unfair to blame this on Linux programs or programmers. Normally it's the user's responsibility to ensure that their compiler searches for include files, etc, in the appropriate place. Many Linux distributions put everything in /usr/include, which is searched by default. FreeBSD puts stuff from ports in /usr/local/include which isn't searched by default. I find that behavior inconvenient, which is why I set those environment variables, so I don't have to think about it. -- Nate Eldredge [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: includes, configure, /usr/lib vs. /usr/local/lib, and linux coders
On Fri, 31 Oct 2008, Nate Eldredge wrote: On Fri, 31 Oct 2008, Steve Franks 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). C_INCLUDE_PATH=$C_INCLUDE_PATH:/usr/local/include LIBRARY_PATH=$LIBRARY_PATH:/usr/local/lib export C_INCLUDE_PATH LIBRARY_PATH ./configure gmake Adjust as appropriate if using csh. Personally, I set those environment variables in my .profile. By the way, I think you're being a little unfair to blame this on Linux programs or programmers. Normally it's the user's responsibility to ensure that their compiler searches for include files, etc, in the appropriate place. Many Linux distributions put everything in /usr/include, which is searched by default. FreeBSD puts stuff from ports in /usr/local/include which isn't searched by default. I find that behavior inconvenient, which is why I set those environment variables, so I don't have to think about it. I don't really care who's to blame (I'd guess I'd blame both the Linux distros and the Linux application developers), but the move to put everything in /usr/include and /usr/lib annoys the heck out of me. It blurs the line between the base OS and installed 3rd party software. Perhaps that's because Linux is really just a kernel, and to the distributors - most, if not all, of their software is 3rd-party. It's really nice to be able to install 3rd-party software so that it doesn't affect the base OS. On FreeBSD, it's easy enough just to 'rm -rf /usr/local' and start fresh without having to worry about screwing up the base OS. -- DE ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: includes, configure, /usr/lib vs. /usr/local/lib, and linux coders
On Friday 31 October 2008 20:30:46 Steve Franks 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). ./configure CPPFLAGS=-I/usr/local/include LDFLAGS=-L/usr/local/lib They should consider using pkg-config in their configure script to locate libusb and libftdi. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
