> Am 18.09.2019 um 09:50 schrieb Laurent Bercot <ska-skaware_at_skarnet.org>:
>
>
>>> It's a difference whether you have to run the entire configure stage
>>> for a new target on the target first or know maybe platform, cpu,
>>> library or kernel issues before and can "cache" these ;)
>
> You mean... like adding specific -l flags and a list of kernel issues
> to a database you then read from? :P
>
> Again, you can't get around this, no matter what words you employ to
> describe the mechanism. Either you have a sysdeps database, and things
> work, or you don't, and they don't. You seem to believe that autotools
> somehow performs magic that other build systems don't; I can assure you
> it's not the case.
I don't. I just believe in "override what is necessary", not "what could
possible go wrong".
So having a overall database which must be filled with each probe is wrong,
the answer you gave later - having a --with-sysdep-K=V is right.
Really cool would be a list of possible (not only required) K.
>>> Case A and B are seriously no problem when the configuration script
>>> respect CPP, CPPFLAGS, CC, CFLAGS, CXX, CXXFLAGS, LD, LDFLAGS,
>>> LDDLFLAGS, CCLD, CCLDFLAGS, ... for HOST_*, BUILD_* and TARGET_*
>>>
>>> skaware doesn't - so the first failure came by not respecting
>>> --sysroot=/path/to/... options for cc and ld etc.
>
> skaware configure scripts respect CC, CFLAGS, CPPFLAGS and LDFLAGS.
> And that's all that's needed to make the build work in all cases.
I attach the script which is preparing the environment (you might have
seen how I deal with desired shell variables).
Maybe that explains better what I try to express.
>>> Yes, that is probably a real question. OTOH - why do you care?
>>> Is it, because you might call malloc(0) and the returned MULL
>>> is handled as an error? Is there a sane way to handle the memory
>>> management by not relying on that quirk?
>
> There are many ways to handle memory management while working around
> that quirk, but it's a brain tax on the application developer, who
> has better things to think about; and when you add quirk after quirk
> after quirk, writing portable programs becomes a nightmare.
> Working around quirks is precisely one of the things that skalibs does,
> so it's its *job* to care about those things.
Sure, but there're sometimes easier ways.
>>> Would it be sane to just provide those sysdeps you can't probe?
>
> Yes, absolutely. Finally we're making progress. :)
>
>
>>> That's why I suggested autoconf. By default, anything is guessed.
>>> And those which can't, can be provided by flags or ac_av_$check.
>
> My (main) criticism of autoconf is that when you don't provide those
> values, autoconf guesses *anyway*. And that is bad.
I've seen how you deal with that. I like the idea and I'm going to
port it to libstatgrab for similar checks.
It's not autoconfs fault when developers of probes make mistakes.
> If you're on the same page as I am that some sysdeps need to be
> hand-provided (or extracted from a database indexed by hw arch, kernel
> and libc, that would be the dream), no matter the build system, then
> we can move forward.
As one who ports software to more or less unknown targets,
I will never agree such a database is a good idea. I requires
software, which should be part of the bootstrap stage being
built later.
>> BTW: It was seriously meant offering help in doing the
>> conversion. And I have no inhibition using AC_RUN_IFELSE
>> where necessary.
>
> I appreciate the offer. However, there is no way skalibs is going
> to use autoconf. autoconf has other problems that makes it unfit
> for skaware - lack of simplicity, for one.
Depends of the point of view. It lacks simplicity it the first
shot. It took me 3 month of full-time development to figure out
the simplicity and how to use it.
But I kept on it, since I learned the simplicity for packagers
from the first day on.
> What I *can* do, though, is change the skalibs build system so that
> on cross-compilation, you only need to provide the few sysdeps that
> cannot be probed at all.
And you did that and it looks very good.
> It would probably even be possible to provide those sysdeps in the
> form of ac_cv_$something environment variables to configure, if you
> insist (but I can't commit to that before starting to work on the
> thing and seeing what format would be easier to deal with).
>
> How does that sound?
That sounds exciting ;)
Even if I don't need ac_cv_* stuff - any reasonable way of handling
those stuff is fine. The reason why I talk "autoconf" is, autoconf
is very good known in how to deal with it on cross-compiling. It
is known how to debug it when probes go wrong, how to intercept
and how to tweak.
It avoids to do round after round fixing configure stage issues
and wasting time of software author and software packager.
It's configure time stuff - and it should go for the developer
heck out of the way ;)
CMake was created, because of autoconf is big and ugly and has dark,
hidden magic. And do you know: nowadays CMake scripts are even
more ugly than autoconf, the do not distinguish between sysroot and
sdkroot, mix host, build and target paths, have even more magic
deeply hidden in CMake core.
Waf has a similar history. Perl5 configure - a nightmare ...
Anyway - as long as you as author invest your effort so quick
and that kind of solution oriented - who am I to throw carrots :)
Cheers
--
Jens Rehsack - rehsack_at_gmail.com
Received on Fri Oct 25 2019 - 14:21:17 UTC