Alon Bar-Lev wrote:
> OK, I will make them available again once all the other is setup.
> The problem is that it always link the project if you make x86...
At least for me that is not a problem. This how I test it:
make x86
<run some tests>
make aespipe
<run some tests>
<realize that I forgot some tests>
make x86
<run more tests>
make aespipe
<run more tests>
> Can the aespipe be converted to generic so we have sane rules?
"make aespipe" target has been there for a long time. Breaking existing
build scripts is not cool, so I prefer to keep it as it is.
> I took another approach please have a look at build6.
Merged most of configure.ac bits. Dropped most of Makefile.in bits.
VPATH=@srcdir@ in Makefile is not portable. x86/amd64 detection is still
using $CC wrapped 'ld --verbose' as it was in build4. That is because it
provides much better guarantee that there is GNU binutils/assembler
underneath. Automatically enabling x86/amd64 on other assemblers is a little
bit risky.
My current version is attached, excluding generated ./configure
Diff against unmodified aespipe-v2.3e
> I disagree... The shorter makefile is much clearer... If there is a
> need for customization a special rule may be written.
Opinions vary.
Have you considered what kind of mess results if all sources are compiled
using shorter Makefile, and you need compile one source file using two
different defines for two different programs? If foo program needs -DFOO,
and bar program needs -DBAR, worst case is that you may have to compile all
sources twice, even though only one source file needs to be compiled twice.
--
Jari Ruusu 1024R/3A220F51 5B 4B F9 BB D3 3F 52 E9 DB 1D EB E3 24 0E A9 DDAttachment:
aespipe-v2.3e-20081106.diff.bz2
Description: Binary data
