[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [lwip-devel] Transition to CMake?
From: |
address@hidden |
Subject: |
Re: [lwip-devel] Transition to CMake? |
Date: |
Fri, 27 Apr 2018 20:33:28 +0200 |
User-agent: |
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 |
Grant
On 27.04.2018 18:41, Grant Erickson wrote:
[..]
By far and away, for moderate- to reasonably-complex packages, the
build system infrastructure of choice—for better or worse—is GNU
autotools.
That's *your opionion*. I wouldn't speak of *is* here.
Anyway, as you noted below, for those not knowing autotools, as you
stated below it can be hard for beginners. And reading some posts on
lwip-users, I don't think it's a good idea to use autotools for lwIP,
which is a library wihout too much code pulled in.
But out of curiosity, what would you expect from autotools for lwIP? I'd
expect that cc.h and some of the functions declared in def.h could be
autodetected. Any more? I don't suppose autotools would help anything in
opt.h/lwipopts.h.
And we would still get makefiles in the end, would we?
And how would it work on windows? I don't want people to have people to
install cygwin or mingw or something to compile the win32 port ;-)
I rarely have run into CMake (perhaps on one or two occasions at most)
for open source projects, particularly those for embedded systems.
Neither did I. That doesn't mean it's not good.
However, I don't really have a strong opinion on this. I still want an
msvc project to be available in the windows port without having to
install cmake.
Other than that, the question of make, cmake or anything else is rather
a question for contrib, is it? When keeping the (relatively new) file
Filelists.mk, we can just have the same thing for cmake. I doesn't mean
people have to compile lwIP with cmake. It would just mean people would
have to start with cmake when compiling the unix port etc...
Simon