--includedir=/usr/include vs --includedir=$(STAGING_DIR)/usr/include
Noticed that some .mk files use different --includedir= configure options. Shouldn't --includedir=/usr/include be used everywhere?
Cheers,
Signature · 1 line
Cristian
Quoted 3 lines
Noticed that some .mk files use different --includedir= configure options. Shouldn't --includedir=/usr/include be used everywhere?
With the recent changes that buildroot has undergone, I actually think this is a good idea. Any objections to getting rid of 'include' in the staging directory all together and going to 'usr/include'?
-Steve
[Buildroot] --includedir=/usr/include vs --includedir=(STAGING_DIR)/usr/include
Quoted 6 lines · Steven J. Hill
Quoted 3 lines
Noticed that some .mk files use different --includedir= configure options. Shouldn't --includedir=/usr/include be used everywhere?
With the recent changes that buildroot has undergone, I actually think this is a good idea. Any objections to getting rid of 'include' in the staging directory all together and going to 'usr/include'?
That's fine with me. But my question was:
--includedir=/usr/include vs --includedir=$(STAGING_DIR)/usr/include
^^^^^^^^^^^^^^Cheers,
Signature · 1 line
Cristian
[Buildroot] --includedir=/usr/include vs --includedir=(STAGING_DIR)/usr/include
Quoted 5 lines · Cristian Ionescu-Idbohrn
Quoted 3 lines · Steven J. Hill
Quoted 3 lines
Noticed that some .mk files use different --includedir= configure options. Shouldn't --includedir=/usr/include be used everywhere?
Quoted 8 lines
Quoted 3 lines
With the recent changes that buildroot has undergone, I actually think this is a good idea. Any objections to getting rid of 'include' in the staging directory all together and going to 'usr/include'?
That's fine with me. But my question was:
--includedir=/usr/include vs --includedir=$(STAGING_DIR)/usr/include
^^^^^^^^^^^^^^
depending on the package --prefix=$(STAGING_DIR)/usr
is enough and all other (except, perhaps specifying the location of $(STAGING_DIR)/etc) are not needed anymore.
There are indeed quite some packages that are not yet converted. Patches to clean those up are very welcome.
[Buildroot] --includedir=/usr/include vs --includedir=(STAGING_DIR)/usr/include
Quoted 4 lines · Bernhard Fischer
Quoted 2 lines
--includedir=/usr/include vs --includedir=$(STAGING_DIR)/usr/include
^^^^^^^^^^^^^^depending on the package --prefix=$(STAGING_DIR)/usr is enough
^^^^^^^^^
Could you please be more verbose? How does one identify which is which?
Cheers,
Signature · 1 line
Cristian
[Buildroot] --includedir=/usr/include vs --includedir=(STAGING_DIR)/usr/include
Quoted 9 lines · Cristian Ionescu-Idbohrn
Quoted 4 lines · Bernhard Fischer
Quoted 2 lines
--includedir=/usr/include vs --includedir=$(STAGING_DIR)/usr/include
^^^^^^^^^^^^^^depending on the package --prefix=$(STAGING_DIR)/usr is enough
^^^^^^^^^
Could you please be more verbose? How does one identify which is which?
packages that use autoconf usually have:
Installation directories:
--prefix=PREFIX install architecture-independent files in
PREFIX
[/usr/local]
Fine tuning of the installation directories:
--bindir=DIR user executables [EPREFIX/bin] --sbindir=DIR system admin executables [EPREFIX/sbin] --libexecdir=DIR program executables [EPREFIX/libexec] --datadir=DIR read-only architecture-independent data
[PREFIX/share]
--sysconfdir=DIR read-only single-machine data [PREFIX/etc]
--sharedstatedir=DIR modifiable architecture-independent data
[PREFIX/com]
--localstatedir=DIR modifiable single-machine data [PREFIX/var] --libdir=DIR object code libraries [EPREFIX/lib] --includedir=DIR C header files [PREFIX/include] --oldincludedir=DIR C header files for non-gcc [/usr/include] --infodir=DIR info documentation [PREFIX/info] --mandir=DIR man documentation [PREFIX/man]
So, for packages that actually install to and use config files from sysconfdir, these should live in $(TARGET_DIR)/etc (resp $(STAGING_DIR)/etc) and not in $(TARGET_DIR)/usr/etc
libpcap, for example can be configured with --prefix=/usr
and installed with
$(MAKE) DESTDIR=$(STAGING_DIR) -C $(LIBPCAP_DIR) install (assuming that it doesn't install anything into /etc).
See?
PS: Of course there is DESTDIR vs. PREFIX. Look at the respective Makefile{.am,.in,}
[Buildroot] --includedir=/usr/include vs --includedir=(STAGING_DIR)/usr/include
Quoted 9 lines · Bernhard Fischer
Quoted 8 lines · Cristian Ionescu-Idbohrn
Quoted 4 lines · Bernhard Fischer
Quoted 2 lines
--includedir=/usr/include vs --includedir=$(STAGING_DIR)/usr/include
^^^^^^^^^^^^^^depending on the package --prefix=$(STAGING_DIR)/usr is enough
^^^^^^^^^
Quoted 8 lines
Quoted 1 line
Could you please be more verbose? How does one identify which is which?
packages that use autoconf usually have:
Installation directories:
--prefix=PREFIX install architecture-independent files in
PREFIX[/usr/local]
But of course. Using --prefix=/usr (instead of 10 options) should be enough in most cases. A lot of configure options need removing from the .mk files.
Quoted 3 lines
So, for packages that actually install to and use config files from sysconfdir, these should live in $(TARGET_DIR)/etc (resp $(STAGING_DIR)/etc) and not in $(TARGET_DIR)/usr/etc
Yes.
Quoted 7 lines
libpcap, for example can be configured with --prefix=/usr
and installed with
$(MAKE) DESTDIR=$(STAGING_DIR) -C $(LIBPCAP_DIR) install (assuming that it doesn't install anything into /etc).See?
Quite simple, isn't it :D ?
Quoted 2 lines
PS: Of course there is DESTDIR vs. PREFIX. Look at the respective Makefile{.am,.in,}
Yes.
I was probably not clear enough. Let me try one more time.
--prefix=/usr vs --prefix=$(STAGING_DIR)/usr
^^^^^^^^^^^^^^I noticed use of the -isysroot and --sysroot gcc compiler options. My interpretation of these options after reading the info pages:
,----
| `-isysroot DIR' | This option is like the `--sysroot' option, but applies only to | header files. See the `--sysroot' option for more information. | | `--sysroot=DIR' | Use DIR as the logical root directory for headers and libraries. | For example, if the compiler would normally search for headers in | `/usr/include' and libraries in `/usr/lib', it will instead search | `DIR/usr/include' and `DIR/usr/lib'. | | If you use both this option and the `-isysroot' option, then the | `--sysroot' option will apply to libraries, but the `-isysroot' | option will apply to header files. | | The GNU linker (beginning with version 2.16) has the necessary | support for this option. If your linker does not support this | option, the header file aspect of `--sysroot' will still work, but | the library aspect will not.
`----
is that $(STAGING_DIR) is not needed if the gcc option --sysroot=$(STAGING_DIR) is used. Does this make sense?
Cheers,
Signature · 1 line
Cristian
[Buildroot] --includedir=/usr/include vs --includedir=(STAGING_DIR)/usr/include
Quoted 15 lines · Cristian Ionescu-Idbohrn
Quoted 13 lines · Bernhard Fischer
Quoted 9 lines · Cristian Ionescu-Idbohrn
Quoted 4 lines · Bernhard Fischer
Quoted 2 lines
--includedir=/usr/include vs --includedir=$(STAGING_DIR)/usr/include
^^^^^^^^^^^^^^depending on the package --prefix=$(STAGING_DIR)/usr is enough
^^^^^^^^^
Could you please be more verbose? How does one identify which is which?
packages that use autoconf usually have:
Quoted 8 lines
Quoted 4 lines
Installation directories:
--prefix=PREFIX install architecture-independent files in
PREFIX[/usr/local]But of course. Using --prefix=/usr (instead of 10 options) should be enough in most cases. A lot of configure options need removing from the .mk files.
/me nods
[snip overall happy agreement]
Quoted 9 lines
Quoted 7 lines
libpcap, for example can be configured with --prefix=/usr
and installed with
$(MAKE) DESTDIR=$(STAGING_DIR) -C $(LIBPCAP_DIR) install (assuming that it doesn't install anything into /etc).See?
Quite simple, isn't it :D ?
yep :)
Quoted 33 lines
Quoted 3 lines
PS: Of course there is DESTDIR vs. PREFIX. Look at the respective Makefile{.am,.in,}
Yes.
I was probably not clear enough. Let me try one more time.
--prefix=/usr vs --prefix=$(STAGING_DIR)/usr
^^^^^^^^^^^^^^I noticed use of the -isysroot and --sysroot gcc compiler options. My interpretation of these options after reading the info pages:
,----
| `-isysroot DIR' | This option is like the `--sysroot' option, but applies only to | header files. See the `--sysroot' option for more information. | | `--sysroot=DIR' | Use DIR as the logical root directory for headers and libraries. | For example, if the compiler would normally search for headers in | `/usr/include' and libraries in `/usr/lib', it will instead search | `DIR/usr/include' and `DIR/usr/lib'. | | If you use both this option and the `-isysroot' option, then the | `--sysroot' option will apply to libraries, but the `-isysroot' | option will apply to header files. | | The GNU linker (beginning with version 2.16) has the necessary | support for this option. If your linker does not support this | option, the header file aspect of `--sysroot' will still work, but | the library aspect will not.
Quoted 4 lines
`----
is that $(STAGING_DIR) is not needed if the gcc option --sysroot=$(STAGING_DIR) is used. Does this make sense?
yes, it does in my POV. IIRC the old, unsupported (by upstream) gcc versions without sysroot support pass the staging_dir via -I and -L, but you should double check if a non sysroot-enabled toolchain still builds them fine, i guess.
cheers,
[Buildroot] --includedir=/usr/include vs --includedir=(STAGING_DIR)/usr/include
In reply to Bernhard FischerQuoted 15 lines · Bernhard Fischer
Quoted 5 lines · Cristian Ionescu-Idbohrn
Quoted 3 lines · Steven J. Hill
Quoted 3 lines
Noticed that some .mk files use different --includedir= configure options. Shouldn't --includedir=/usr/include be used everywhere?
Quoted 8 lines
Quoted 3 lines
With the recent changes that buildroot has undergone, I actually think this is a good idea. Any objections to getting rid of 'include' in the staging directory all together and going to 'usr/include'?
That's fine with me. But my question was:
--includedir=/usr/include vs --includedir=$(STAGING_DIR)/usr/include
^^^^^^^^^^^^^^
Quoted 6 lines
depending on the package --prefix=$(STAGING_DIR)/usr
is enough and all other (except, perhaps specifying the location of $(STAGING_DIR)/etc) are not needed anymore.There are indeed quite some packages that are not yet converted. Patches to clean those up are very welcome.
In the same go a cleanup of all libdir variables in lib<name>.la should be done? I see some libraries have /usr/lib there, and it can make some confusing moments if you have the library installed on the build machine as well.
Signature · 4 lines
With kind regards, Hans-Christian Egtvedt, siv.ing. (M.Sc.) Applications Engineer - AVR32 System Solutions - Atmel Norway
[Buildroot] --includedir=/usr/include vs --includedir=(STAGING_DIR)/usr/include
Quoted 21 lines · Hans-Christian Egtvedt
Quoted 19 lines · Bernhard Fischer
Quoted 5 lines · Cristian Ionescu-Idbohrn
Quoted 3 lines · Steven J. Hill
Quoted 3 lines
Noticed that some .mk files use different --includedir= configure options. Shouldn't --includedir=/usr/include be used everywhere?
Quoted 8 lines
Quoted 3 lines
With the recent changes that buildroot has undergone, I actually think this is a good idea. Any objections to getting rid of 'include' in the staging directory all together and going to 'usr/include'?
That's fine with me. But my question was:
--includedir=/usr/include vs --includedir=$(STAGING_DIR)/usr/include
^^^^^^^^^^^^^^depending on the package --prefix=$(STAGING_DIR)/usr
is enough and all other (except, perhaps specifying the location of $(STAGING_DIR)/etc) are not needed anymore.
Quoted 7 lines
Quoted 2 lines
There are indeed quite some packages that are not yet converted. Patches to clean those up are very welcome.
In the same go a cleanup of all libdir variables in lib<name>.la should be done? I see some libraries have
/usr/libthere, and it can make some confusing moments if you have the library installed on the build machine as well.
AFAICS yes.
The target_dir .la should use the absolute target-pathes (e.g. /usr/lib) and the staging_dir .la should use absolute cross-pathes ($(STAGING_DIR)/usr/lib for example), yes.
IIRC some packages -- those that are actually used as prerequisites for other packages in build_ARCH -- already fixup their .la via $(SED).