[geeks] UNIX development and makefile discussion

[microcode at zoho.com]

On Wed, Aug 14, 2013 at 04:06:26PM +0200, Jochen Kunz wrote:
> On Wed, 14 Aug 2013 11:27:05 +0000
> microcode at zoho.com wrote:
> 
> >  Aside from writing portable code what should I be considering?
> cmake: http://www.cmake.org/
> cmake will perform automatic tests to find platform speciffic options
> like where include files are to find and then it will generate
> makefiles.

I have heard of cmake and of course autotools but I don't know big a project
has to be before that stuff starts making sense. What really strikes me
about UNIX is how much the tools get in my way and take up much of my time.
I would be inclined to avoid anything that makes that worse or creates any
dependencies in code or procedurally as much as I possibly can. So far I'm
happy with simple makefiles. It's really how to organize a project in UNIX
that I'm asking about and after I decide which approach to try next then
I'll know more about whether it's time for a bigger hammer.

If cmake is warranted for a project with a dozen source files (not sure how
big it will grow to) then I'll have to look into it. It will be important to
me if cmake builds easily with Solaris Studio and doesn't have an annoying
installed footprint or dependencies. I understand cmake is supposed to be
about "cross platform" but I read comments that it is changing too fast and
that things break. I don't know how far evolved it is now or if those
comments are still true. 

> Think of it as "meta-make". cmake eases the tedious process of writing
>  makefiles and organizing them considerably. 

At this point writing makefiles isn't a major issue for me. It happened in
stages and I have good skeletons for the kind of work I'm doing. My problem
is more about how to organize the code so I can manage pieces the way I like
to work. I probably should have tried to make a picture to explain what I'm
asking about but the ones I draw usually don't help that much.

In this project I have different functional areas that I have separate
makefiles for that all build and run fine. The problem is and it's really a
good problem to have is that each of the functional areas are starting to
rely on code that could be shared. First I wrote a piece of code to be
invoked from one functional piece but then I realized I also need to use it
in another functional piece. Now it no longer makes sense for me to organize
the code in functional subdirectories because increasingly the functional
areas are relying on common code that used to be specific to one functional
area. Do I create yet another subdirectory for common code? But if I work in
one directory and build everything there it becomes a huge pile of source
and object code and executables and doesn't seem very manageable. All this
is part of what I would appreciate some perspective on from people who
develop in UNIX since this is new to me. I don't know what my choices
are. The choices seem to be either one directory full of everything which
means one big makefile and easier testing, or subdirectories for common code
and functional pieces and tests and recursive makefiles to build and test
everything and then things are organized more effectively but now building
and testing is harder because the executables are no longer all in one
place. 

> The GNU autotools (autoconf, automake, auto...) do similar things. But
> I do not recommend them. Every time I have to use autoconf it drives me
> insane because it is so arcane. It polluts projects with GNUisms and
> simply doesn't work well in todays *ix environement. Most autoconf
> scripts I came across are badly written (due to autoconfs idiosyncrasy)
> and thus don't work well. So I have to play dirty tricks to autoconf to
> make it do things the way I need. So instead of doing things
> automaticaly I have to do them manually and doing it manualy is a PITA
> with autoconved stuff. Avoid autoconf like the plague!

Thanks. This much I did know. I tend to avoid gnu-anything as much as
possible for many reasons. It's one of the main reasons I like Solaris for a
development environment. But it is nice to hear somebody with similar
opinions! Very nice indeed!