SPECS: ndiswrapper.spec - new way of modules build

[kiesiu]

kiesiu wrote:
> areq wrote:
>> -    rm -rf include
>> -    install -d include/{linux,config}
>> -    ln -sf %{_kernelsrcdir}/config-$cfg .config
>> -    ln -sf %{_kernelsrcdir}/include/linux/autoconf-$cfg.h
>> include/linux/autoconf.h
>> -    ln -sf %{_kernelsrcdir}/include/asm-%{_target_base_arch}
>> include/asm
>> -    ln -sf %{_kernelsrcdir}/Module.symvers-$cfg Module.symvers
>> -    touch include/config/MARKER
>> +    install -d o/include/linux
>> +    ln -sf %{_kernelsrcdir}/config-$cfg o/.config
>> +    ln -sf %{_kernelsrcdir}/Module.symvers-$cfg o/Module.symvers
>> +    ln -sf %{_kernelsrcdir}/include/linux/autoconf-$cfg.h
>> o/include/linux/autoconf.h
>> +    %{__make} -C %{_kernelsrcdir} O=$PWD/o prepare scripts
> 
> 
> Czy tylko mnie się tak wydaje, czy po czymś takim jak będziemy budować z
> --target innym niż architektura na której to budujemy, tak w o/include2
> będziemy mieć link do plików nagłówkowych dla nieodpowiedniej architektury?
> 
> Przykład. Jeśli na i686 dam --target amd64 to mi teorzy link do katalogu
> asm-i386 zamiast asm-x86_64.
> 
> Poprawiając ostatnią zacytowaną linijkę na:
> 
> %{__make} -C %{_kernelsrcdir} O=$PWD/o ARCH=%{_target_base_arch} prepare
> scripts
> 
> rozwiązujemy wszelkie problemy ;) No chyba, że taki jest zamiar i tak ma
> być, jak jest teraz.
> 
Widzę, że nie zainteresowało to nikogo. To znaczy, że tak ma być i
opisany powyżej przeze mnie problem w niczym nie przeszkadza?

-- 
pozdrawiam,
Łukasz Kieś