[Buildroot] something (slang?) creates buildroot/build_i486/staging_dir/include

[Buildroot] something (slang?) creates buildroot/build_i486/staging_dir/include

[Cristian Ionescu-Idbohrn]

See attachment, and that may be screwing up things.
See also my previous posts.


Cheers,

-- 
Cristian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: include.gz
Type: application/octet-stream
Size: 3171 bytes
Desc: 
Url : http://busybox.net/lists/buildroot/attachments/20070729/07cd3efe/attachment.obj 

[Buildroot] something (slang?) creates buildroot/build_i486/staging_dir/include

[Cristian Ionescu-Idbohrn]

On Sun, 29 Jul 2007, Cristian Ionescu-Idbohrn wrote:

> See attachment, and that may be screwing up things.
> See also my previous posts.

Moving buildroot/build_i486/staging_dir/include away will allow libpcap,
tcpdump, wget and which to build. Though I still have troubles building
gawk and util-linux :(


Cheers,

-- 
Cristian

[Buildroot] [patch] slang.mk (was: something (slang?) creates buildroot/build_i486/staging_dir/include)

[Cristian Ionescu-Idbohrn]

On Sun, 29 Jul 2007, Cristian Ionescu-Idbohrn wrote:

> On Sun, 29 Jul 2007, Cristian Ionescu-Idbohrn wrote:
>
> > See attachment, and that may be screwing up things.
> > See also my previous posts.
>
> Moving buildroot/build_i486/staging_dir/include away will allow libpcap,
> tcpdump, wget and which to build. Though I still have troubles building
> gawk and util-linux :(

Replying to myself :)
Yes, package/slang/slang.mk screws up things :(
Please consider applying the attached patch.

I do not know much about the buildroot backyard, but I read some
discussions about the include-dir being $(STAGING_DIR)/usr/include/
and not $(STAGING_DIR)/include/. Wouldn't it be a good idea to make that a
variable somewhere in the top makefiles, something like:

  STAGING_INCLUDE_DIR = $(STAGING_DIR)/usr/include/

and change all .mk files to use that instead? That should give one point
of control on where the header files are installed and avoid errors and
confusion.

I noticed the .mk files use `cp' rather than `install', to install various
files. Is there a good reason for that?

On my box (debian sid), these two make variables:

  INSTALL = /usr/bin/install
  RM = rm -f

are predefined. Why not use them in the make files. Top makefiles would
again be the place to control the behaviour, should there be any
compatibility concerns with various distributions.

Shouldn't the clean-targets even clean stuff that was installed under the
STAGING_DIR?


Cheers,

-- 
Cristian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: slang.mk.patch
Type: text/x-diff
Size: 1426 bytes
Desc: 
Url : http://busybox.net/lists/buildroot/attachments/20070729/04170d0c/attachment-0001.bin 

[Buildroot] [patch] slang.mk (was: something (slang?) creates buildroot/build_i486/staging_dir/include)

[Ulf Samuelsson]

> 
> I do not know much about the buildroot backyard, but I read some
> discussions about the include-dir being $(STAGING_DIR)/usr/include/
> and not $(STAGING_DIR)/include/. Wouldn't it be a good idea to make that a
> variable somewhere in the top makefiles, something like:
> 
>  STAGING_INCLUDE_DIR = $(STAGING_DIR)/usr/include/
> 
Some stuff is normally installed in $(STAGING_DIR)/usr/include/ and 
others in $(STAGING_DIR)/include/, so I do not think it will work

> and change all .mk files to use that instead? That should give one point
> of control on where the header files are installed and avoid errors and
> confusion.
> 


Best Regards
Ulf Samuelsson                ulf at atmel.com
Atmel Nordic AB
Mail:  Box 2033, 174 02 Sundbyberg, Sweden
Visit:  Kavalleriv?gen 24, 174 58 Sundbyberg, Sweden
Phone +46 (8) 441 54 22     Fax +46 (8) 441 54 29
GSM    +46 (706) 22 44 57

Technical support when I am not available:
AT90 AVR Applications Group: mailto:avr at atmel.com
AT91 ARM Applications Group: mailto:at91support at atmel.com
AVR32 Applications Group        mailto:avr32 at atmel.com
http://www.avrfreaks.net/;            http://avr32linux.org/
http://www.at91.com/ ;                ftp://at91dist:distrib at 81.80.104.162/

[Buildroot] [patch] slang.mk (was: something (slang?) creates buildroot/build_i486/staging_dir/include)

[Bernhard Fischer]

On Sun, Jul 29, 2007 at 11:38:54AM +0200, Cristian Ionescu-Idbohrn wrote:
>On Sun, 29 Jul 2007, Cristian Ionescu-Idbohrn wrote:
>
>> On Sun, 29 Jul 2007, Cristian Ionescu-Idbohrn wrote:
>>
>> > See attachment, and that may be screwing up things.
>> > See also my previous posts.
>>
>> Moving buildroot/build_i486/staging_dir/include away will allow libpcap,
>> tcpdump, wget and which to build. Though I still have troubles building
>> gawk and util-linux :(
>
>Replying to myself :)
>Yes, package/slang/slang.mk screws up things :(

Applied as r19335. Thanks!

>I do not know much about the buildroot backyard, but I read some
>discussions about the include-dir being $(STAGING_DIR)/usr/include/
>and not $(STAGING_DIR)/include/. Wouldn't it be a good idea to make that a
>variable somewhere in the top makefiles, something like:
>
>  STAGING_INCLUDE_DIR = $(STAGING_DIR)/usr/include/
>
>and change all .mk files to use that instead? That should give one point

No, we do not need a STAGING_INCLUDE_DIR.

Every package that installs headers into $(STAGING_DIR)/include is wrong
(i.e. was not yet corrected to properly install into ../usr/include).

The libraries should be installed to the same dir (/lib vs. /usr/lib) as
on an LFS compliant host (usually into /usr/lib except some rare libs
such as libc).

>of control on where the header files are installed and avoid errors and
>confusion.
>
>I noticed the .mk files use `cp' rather than `install', to install various
>files. Is there a good reason for that?

There is no good reason, no. I'd favour to use $(INSTALL) myself,
patches welcome.
>
>On my box (debian sid), these two make variables:
>
>  INSTALL = /usr/bin/install
>  RM = rm -f
>
>are predefined. Why not use them in the make files. Top makefiles would
>again be the place to control the behaviour, should there be any
>compatibility concerns with various distributions.
>
>Shouldn't the clean-targets even clean stuff that was installed under the
>STAGING_DIR?

yes, it should. Not all packages are yet adjusted to do this. Again,
patches to fix these are welcome.

TIA,
Bernhard