420 lwip lpcopen documentation for origin and patches

[mabeett]

This PR Closes #420

This this patch the origin of lpcopen files is registred in the documentation, as well the information related with patches applied to the original sourcecode.

[mabeett]

Waiting for feedback =)

[mcerdeiro]

Hola Matías, no quiero ser muy mala onda, la idea esta buena, pero me parece tiene un problema y es que si cambian cualquier cosa en los fuentes o el formato de la estructura de directorios hay que adaptar el script. Osea no se si sirve :( si cada 2 anios alguien se tiene que poner a ver el script lo más probable es que prefiera hacerlo a mano...

no se que te parece a vos?

saludos. Mariano.-

[mabeett]

El script es irrelevante. Tengo en mente unas sugerencias posteriores a esta que probablemente requieran de adecuar el script. Lo adecuaré, siendo 50 líneas de shell scripting, no me parece muy complicado. No tiene arreglos ni ninguna característica de bash que lo ponga al margen de ser usado con otros shells.

no se que te parece a vos?

En la actualidad hay un txt con algunas cosas apuntadas de lo que se parchó de lpcopen que no es claro, tampoco se indica el origen de los fuentes. De hecho los parches que sugiero acá exceden lo que indica el txt (y no cambia ningún archivo C).

Hoy traer a lpcopen más nuevo es un dolor de cabeza porque para aplicar los cambios se requeriría antes saber qué intervenciones se hicieron al actual lpcopen 2.16, que a la vez no está claro.

El objeto del parche es dejar en claro los parches que se aplicaron. En la actualidad eso no es posible porque hubo el repositorio cambios de codificación unix a dos o al revés y se estropea comparar cambios para atrás, al menos verlos uno como humano. Para constatarlo pedir log de master en el directorio externals/lwip/src/core/ (no hay intervenciones en la lógica de ese código); luego pedir differencias de master con el anteúltimo commit de esde log para el mismo directorio git diff master 90171ff87c3 -- externals/lwip/src/core/

Para la idea de los parches basé en lo que he visto en los paquetes debian. Cuando uno hace apt-get source xterm se descarga el tarball original, también un tarball que tiene los cambios aplicados al original y se compone todo en un directorio, la información de los cambios respecto del upstream están en formato patch en xterm-297debian/patches. En el caso de debian, existe una scriptería que compone el paquete aplicando los parches. En mi caso para validar cada parche hice un script y ya que lo estaba haciendo lo hice parte del commit también.

Lo menos relevante es el script, la parte importante es dejar en claro qué se parcha y con qué objeto, por eso son parches separados y cada uno tiene un comentario que puse yo con algo de imaginación porque no fui quien intervino el código original.

No creo que en la actualidad con la información que existe hoy en el repositorio sea más sencillo portar un lpc más nuevo. Lo comento porque estuve los últimos 3 días comparando los archivos para generar los parches. Ese será tiempo adicional a agregar a cada actualización.

Tengo en mente traer lwip desde el repositorio de lwip y a la vez llevar los fuentes de lpc la estructura de directorios de $(ARCH)/$(CPUTYPE)/ y eso requerirá alterar el Makefiles (pero eso serán otros MR), de manera que alterar el script me parece hasta trivial.

En algunos proyectos como openwrt, al trabajar con los fuenes ajenos se hace parecido a la manera de debian, pero bajando el tarball desde el servidor ftp/http original, todo eso se orquesta desde makefile. Está muy bueno. Intenté agregar el target a un makefile pero no supe hacerlo y desistí. Es por eso que el script recibe de argumento el rootdir que podría llamar makefile desde sus variables.

Estoy atento a sus comentarios, mts

[mabeett]

Estaba pensando que se podría poner un instructivo en un archivo markdown (o en el existente) con los pasos que hace el scrip y algunas explicaciones. De esa manera también quedaría claro qué archivos se copian de lpcopen. No obstante quien quiera poner al día el lcpopen de LWIP tendría que actualizar ese documento en vez del script.

[mabeett]

Agregué comentarios al script, de manera que es más claro el código que ejecuta. Pasar a markdown sería relativamente poco trabajo. No obstante en el copiar/pegar está casi el mismo riesgo de quien ejecuta el sctript. Como cualquier registro documental precisará ser actualizado.