z-man wrote:
We use Visual Studio/C++ 6. Isn't it so that cygwin compiled binaries need cygwin installed? Would non mingw be better for us? For compiling, I mean. As build environment, cygwin would do.
No, you only need to distribute certain dll's, depending on what you use. It's theoretically possible to build without linking to any of the Cygwin POSIX layer dll's (that's all they are), but in practice I've never managed to do so. So it would make the distributable bigger.
Besides that, GNU make can use Microsoft's compiler. The old Mozilla build system did exactly this.
However, that's not entirely necessary either.
You could keep on using VC++ to build the distributable and then just use Cygwin for the bash it comes with, and the python, and that gives you a common environment for all plfatforms to build distributables with. So the same makefiles you use would work on all platforms, and would be customized as needed to do what is needed for each platform.
I'm a bit familiar with distutils; in my numerics project for my thesis I use python as a flexible build system and use distutils to give me the right compiler options for shared libraries.
Distutils rules.
That's all I can say. I have a few complaints, but I have a few complaints about everything. Distutils just plain rules.
I've customized mine further so that if it's running in Windows, it also copies the NSIS installer script to the dist directory and then calls NSIS to build the installer.
Sounds cool!
If you can send me a zipfile of a Windows source directory after you've compiled it and list the files that need to go into the distributable, I can see about customizing my generic NSIS script for arma. The only catch is, to build the distributable you have to use NSIS (obvious, I guess). The advantage, and the reason I use NSIS, is that since it has a wonderful commandline version, it's easy to automate builds. (It is also very competitive in its feature set, but that's a different discussion)
Depending on python should be no problem since it is generally available. Heck, I'm using a distribution that entirely depends on python
Not being able to integrate the debian build is problematic, however. Although I don't even know how the debian stuff works when you install it by hand. How about a make file that calls smaller python scripts for individual tasks? We'll still want to distribute them across several persons or rerun only those parts of the build process that failed last time, and make is good at handling such things.
Theoretically, making it support debian packages should be a matter of just writing a new distutils module. Having not done that, I'd prefer not to do it now. Instead, work up a bash script that'll do it and make a makefile call for it. I can build a setup.py to handle the source tarball, rpm-building, a windows distributable (based on NSIS, or any arbitrary system you send me, but you probably should send me command line arguments and so forth since I only know NSIS right now), and even a generic .tar.gz binary. Then make makefile calls for those and we're set.
Using python's distutils for automating tasks doesn't have to mean "make a separate build system". It should be integrated into the makefiles, I think.
Ideally a guy would be able to do:
cvs update && make && make bdist
and have an rpm/source tarball/self-installer/disk image, depending on his platform. So I'm talking about grafting it after the part the actually builds the executables and libraries.
