On 12/29/2011 22:42, Peter Meyer wrote: >> /off topic rant >> >> Most custom Makefiles cannot handle systems that are different from the >> developer's, requiring manual editing to fix it. This gets very tedious >> when you keep running into them over and over. > > Thadt are the problems you have to deal with it, but thadts no Problem, > if you allways > have a bunch of vmware Images so you can test check the git checkouts. > >
That is fine and dandy if you have access to said platform and they run at reasonable performance. Now, try that again when porting code to small non-x86 platforms. I guess you don't mind building the GCC on your phone or prototyping board. >> Did I mention different authors have different naming conventions and >> styles? Do you set CFLAGS? COMPLE_FLAGS? OPTIMIZATION_FLAGS? So many > > I do not agree.In reality, there are only a few things you must check > (for example: if Arch type > is only x86 and x86_64) , maybe a bit more if you use profile guided > optimization e.c.t. > > CFLAGS are not only used for optimizations. So how do I tell from the CPU type if I should use ELF or PE semantics? Where do I put my compiler flags to do some security hardening or custom linker scripts? How do I make compiler use non-default libdir/headers dir? >> Mac, Solaris and FreeBSD already have a shell interpreter, not sure why > / rant on > > In reality they have diffrent interpreters. Some having bash and you > cannot simply > change it (espacially on Mac, the bash is needed for internal OS > puporses) and shared > libs often are builded as framework ant not simply as shared or static > type. You also > have to binary patch executables and shared object so you can create a > setup dmg > File to provide a setup download. and in Solaris, there has a LOT > changed the last > two years. a complet new Packaging system was integrated in (called ICS) > wich > used the scm system bazar. In the wild, if you have a fresh installed > Solaris System > you even dont have access to gcc or binutils and the expected main Compiler > is SUN C/C++ and on older Solaris Versions you have to deal with Blastwave > as thirdparty packaging system. > Autotools already know about those non-gcc compilers, bash isn't a requirement for autotools. I'm sure its able to check the BUILD OS capabilities. Whereas qmake requires you to have some parts of QT installed, cmake needs cmake, both not as common as the basic sh shell. I don't know about how DMG installs go, but I'm sure you can take a peek inside without actually running it first. OSX framework bundling is simply another step in automake, its not hard after you understand the MACH-O manual, or just use libtool to do it for you. > Bottom line: the Operatingsystems are not 100% equal and assumptions or > automated, > generated tasks can be terrible wrong and its hard to figure out what > tools (for example: > qmake) do. QMake for example has an intermediate compiler called moc, > thadt does > things like autotools and after this generates standard GNU Makefiles, > but if moc > has a Problem, then ýou lost and take a look in the autognerated > makefiles to find > out whats going wrong autotools has config.log. Automated buildsystems are still more convenient than those that require special attention on every different platform. Using custom makefiles will only make it worst, since you now have a dozen other authors with their own handcrafted buildsystems to compete with.
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
_______________________________________________ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public