Hi Thomas, first of all, thanks for your rapid answer !
Le vendredi 25 mars 2011 18:59:25, Thomas Gaugler a écrit : > This means spitting the NSIS package into smaller packages to reduce > the load on the build servers for the different architectures and > make sure installer packages can be build on any Debian architecture > with NSIS. Nice goal. Although I don't think it'll be possible to reduce the load by much given your statements below. And nsis is not creating problems buildd-wise from what I could see. > I thought about splitting the NSIS package into: > * compiler and utils (architecture dependent) > * plugins, stubs and resource files (architecture independent - win32) > * plugin development kit (architecture independent - win32) > * documentation and examples (architecture independent) Sounds sane, but maybe a little too overkill: what about one arch:any nsis and one arch:all nsis-common (with the first being compiled on all architecture, the latter not) ? It then depends on what can be achieved when one only installs a subset of the packages and what are the relation between said packages (Depends, Recommends, Enhances, …). > Unfortunately there would be a circular dependency for running the > tests during the package building. The NSIS compiler (makensis) > would need the plugins, stubs and resource package during the test > stage. So I am currently investigating how this issue could be solved > best. Any suggestions in this matter are very welcome. Then you would be forced to do the complete build on all architectures (which is not a problem /per se/; Debian still benefits from having arch:all packages [might it only be for disk space reasons]). > Another advantage of the package splitting would be to have two sets of > plugins/stubs packages for unicode and multibyte character support. What about shipping 4 flavours (possibly co-installable) ? Aka the 4 combinations of the two following options: a) unicode+multibye; b) w64 build. This would produce 4 packages: nsis-w32-unicode, nsis-w32-ansi, nsis-w64- unicode, nsis-w64-ansi (all of them providing "nsis"). What do you think? By the way, AFAICS, the biggest problem currently is that nsis from svn doesn't build on non-Windows toolchains (and the FTBFS is AFAIK due to the unicode patch). I have begun to try to fix this, but failed so far. Have you been more successful ? Cheers, OdyX
signature.asc
Description: This is a digitally signed message part.
