On 29 January 2010 10:32, pancake <pancake_AT_youterm.com> wrote:
> The problem I see in makefiles is that they dont follow a strict usage
> rules and there are no 'standards' on their usage. And this is pretty
> anoying. Because with the makefile approach you end up by implementing
> everything from scratch, there's no set of .mk files to do it magically
> or anything else. And of course that magical approach will only cover
> the build, install and distribution stages.
Well I have some handy templates at hand when creating a new makefile.
> The configure stage is in many situations innecessary, but its just a way
> to do different actions to 'configure' the project. This is:
> - detect libraries, programs
Question is if you need to do this programmatically. The config.mk
approach lists all depencies and required tools for building (or if
one likes one can add them to a README file).
> - check for endianness
> - check cpu
> - check for include files
> - check OS (target,host,..) useful for crosscompiling
> - check for system-related libraries to fit certain features (-lsocket in
> solaris. fex)
Same, config.mk settings imho.
> If you have to do all this job for every project you do.. you will probably
> fail at some point. This is why is good to have a centralized project that
> generates the proper checks to get all this information in a way that
> works on most of systems and most of arquitectures.
The problem is that every system is different and those tools that try
to generalize nearly never get it right.
I'm not against using pkg-config for example in Makefiles, but what
else does one really need?
> If you find a problem in a certain arquitecture you just need to fix it
> in one point, not in all your projects.
What kind of problem are you describing here? I agree the config.mk
approach should be designed in a way that you have one central
config.mk for each target platform that you build for. But what else
do you need? Fixing a problem in such a central config.mk file is as
easier than fixing some script that tries to generate makefiles.
> The problem is that GNU configure sucks, is slow, is dirty, is bloated, is
> full of weird hidden features and lot of collateral issues can easily appear
> which are really hard to debug.
The problem is not the GNU configure is slow, dirty, bloated, the
problem is the idea to generate Makefiles using some script or tool
apart from cp or cat ;)
--Anselm
PS: Amen to Uriel.
Received on Sat Jan 30 2010 - 16:23:29 UTC
This archive was generated by hypermail 2.2.0 : Sat Jan 30 2010 - 16:36:02 UTC