Re: [lwip-users] What is the recommended steps to upgrade to 2.0.0?

[Sergio R. Caprile]

This is my personal opinion, I'm no lwIP developer, just another user.
Your problem is not lwIP's fault but your vendor's fault.
Every port has to reference lwIP files somehow, common practice is to 
use a makefile or an IDE file list. In some cases you can just reference 
directories.
The stack started as an IPv4 stack and so the file was named ip.c; then 
it has grown to support IPv6 and as in every project, files may change 
names to keep consistency and maintainability. If you (or your vendor) 
want(s) to hardcode lwIP into a library, that is your (his) business.
For example, this is my build (bash) script for an example (SMTP) on my 
testbed in Linux:
LWIPDIR="../lwip/src"
CONTRIBDIR="../contrib"
LWIPUNIXDIR=".."
LWIPINCLUDE="-I${LWIPDIR}/include -I${LWIPDIR}/include/ipv4"
PLATFORMINCLUDE="-I${CONTRIBDIR}/ports/unix/include 
-I${CONTRIBDIR}/ports/unix/proj/minimal"
FLAGS=""
CFLAGS="-g -Wall -Dlinux -DIPv4 -fpack-struct -DLWIP_DEBUG ${FLAGS} 
${PLATFORMINCLUDE} ${LWIPINCLUDE} -I${LWIPUNIXDIR} -I."

gcc ${*} -DSMTP_DEBUG=LWIP_DBG_ON ${CFLAGS} -o smtp smtp.c 
${LWIPUNIXDIR}/lwip_unix.o 
${CONTRIBDIR}/ports/unix/proj/minimal/liblwip4.a 
${CONTRIBDIR}/ports/unix/proj/minimal/timer.o 
${CONTRIBDIR}/apps/smtp/smtp.c -I${CONTRIBDIR}/apps/smtp

Here, lwip_unix is where I do the Linux specific stuff.
As you can see, there are not many references to change.

This is part of the config for my project in Keil, whose generated code 
I run on my Cortex-M3 hardware:

<IncludePath>..\;.\;.\lwip-port;.\lwip\src\include;.\lwip\src\include\ipv4
        </IncludePath>
        <Group>
          <GroupName>lwIP</GroupName>
          <Files>
            <File>
              <FileName>udp.c</FileName>
              <FileType>1</FileType>
              <FilePath>.\lwip\src\core\udp.c</FilePath>
            </File>
            <File>
              <FileName>def.c</FileName>
              <FileType>1</FileType>
              <FilePath>.\lwip\src\core\def.c</FilePath>
            </File>
                ...
            <File>
              <FileName>etharp.c</FileName>
              <FileType>1</FileType>
              <FilePath>.\lwip\src\netif\etharp.c</FilePath>
            </File>
          </Files>
        </Group>

As you see, files are referenced by name, and a name change is just a 
matter of watching the "file not found" error and replacing by point and 
click.
I bet many other options will be very similar, so our little effort for 
once in the project lifetime is nothing in comparison to code 
readability and maintainability, and name changes are part of that.