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.

Attachment: 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

Reply via email to