I have a nios2 project where I can do test builds on my own workstation. I also commit code to a version control repository so it can be rebuilt by other developers, or by a build server.The only BSP-relevant files currently under version control are nios.sopcinfo and create-this-bsp - all other BSP files are auto-generated on every full build. I've already changed some details of the BSP by changing create-this-bsp, e.g. adding "--set hal.max_file_descriptors 8" to the arguments for nios2-bsp. This works well and is stable and maintainable across multiple build platforms. Now I want to change one of the driver header files. (Specifically, I want to change the# define of ALT_AVALON_UART_BUF_LEN in altera_avalon_uart.h, but my question isn't really about the uart, it's about best practice with the toolchain.) I can generate a BSP then manually hack the .h file directly - and it works for my local builds. The trouble is, the next time I (or anyone else) regenerates the BSP, the change is lost. I can't find a way to make create-this-bsp generate any value other than the default. Can anyone suggest a stable, maintainable way to change the contents of a driver include file?
OK, managed to find a way.I added my edited version of drivers/inc/altera_avalon_uart.h to version control, then added --cmd set_ignore_file altera_avalon_uart_driver altera_avalon_uart.h true to my nios2-bsp arguments in create-this-bsp, to stop it overwriting my edited file. This does the job, regardless of whether I build it locally or on Jenkins. Panic over. :D