[lug] OT: Makefile oddity

[D. Stimits]

"Michael J. Hammel" wrote:
> 
> Thus spoke D. Stimits
> > Ok, I can later use ${SOMETHING}, even if it is just echo. But, I was
> > coming up with problems of dual attempts to build targets in a project
> > split into separate directories. So I ran with -d for debug mode. Turns
> > out that:
> > include Makefile.something
> >
> > ...is doing the right thing, and after that, it is calling "include" a
> > target! It then tries to figure out how to build Makefile.something,
> 
> This seems about right, and one of the reasons I eventually moved my
> projects (many years preceeding auto-conf) to imake.  Imake will handle
> this situation quite well, as it uses a preprocessor to manage the #includes.

In this case neither imake nor autoconf are an option. On the other
hand, this is a project rearrangement of really ugly directory and build
arrangements that are generally unfriendly to all sorts of tools, and if
it does work, it could pave the way to other configuration tools. If it
fails, it is a guarantee no other tools beyond make will ever exist in
this particular project.

> 
> I use included files in many places, many of which include variables that
> are set using external scripts (GIMPINCS = `gimptool --cflags` for
> example).

Just want to be sure people know, the "include" statement being
considered is in the Makefile itself, so that sub-portions of the
Makefile can be added without messing up the readability of the main
Makefile. So it is make itself that the include has an effect on, and is
completely invisible to all source code.

> 
> > Perhaps I need some sort of dummy rule that will force make to see
> > target "include" as always up-to-date? I want to include separate files
> > for subdirectory definitions, but I want it to only add definitions, I
> 
> You need to force make to preprocess the includes first, then process the
> Makefile a second time, the way imake does with Imakefiles.  Not sure if
> you can do that with make, but possibly if you integrate it with m4 or
> something (not that I know much about m4).

This is actually someone else's code, I'm trying to rearrange it to make
it more viable to use cvs and other tools. Right now it is a mess of
C/C++ mix full of symbolic links. All the output is mixed together, all
of the dependencies are broken, etc, etc. This is the first stage of
cleanup, and if I use m4 or any other tools (like imake or autoconf),
the original author will reject it. If I get separation of input and
intermediate output, one goal will have been achieved. If configuration
files are segregated from source files, another goal will have been
achieved. If I do the above while getting rid of sym links, I'll be
ecstatic because then I can get cvs to be used. Whatever I do, it has to
be via only make, and no other tools (at least for the moment).

> 
> > do not want it to end up doing multiple evaluations of everything under
> > the mistaken assumption that "include Makefile.whatever" is a target and
> > source file. Has anyone here seen this problem before or found a way to
> > deal with it?
> 
> imake - It's not just for X.  And there is a decent text on it from
> O'Reilly:  Managing Portability with imake.

I have the book, it isn't an option for this.

> 
> The easiest way to handle imake is to make use of the imake templates
> delivered with a stock XFree86 installation and use the "xmkmf" script.
> However, you can write your own templates and skip the X stuff altogether.

FYI, some of the projects are completely non-X11, and imake won't even
be installed on many of the build platforms.

D. Stimits, stimits at idcomm.com

> 
> Note that learning imake is a lot less difficult than trying to learn
> auto-conf if you already know Makefile formats.
> --
> Michael J. Hammel                               The Graphics Muse
> mjhammel at graphics-muse.org                      http://www.graphics-muse.com
> ------------------------------------------------------------------------------
> You should not confuse your career with your life. -- Unknown.
> _______________________________________________
> Web Page:  http://lug.boulder.co.us
> Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug