Shared Makefiles and Embedded Function Names

I’ve just discovered that when using the DDE’s Shared Makefiles to build a release version of an application, they appear to very kindly pass -ff to the C compiler… This is great for obfuscation, but personally I’d prefer usable backtraces when things go wrong.

My question is, without hacking around in the shared files themselves, is it possible to turn this off from the top-level project file? It looks as if the files are defining C_NO_FNAMES to be -ff at some point in the process, and then stripping this out when building the debug target. Can it be forcibly unset in some way that I’m missing?

You could use the filter-out operator to remove the switch, after the main makefile has set it to contain the various other incantations. That’s how DbgRules appears to do it.

# COMPONENT, OBJ, and usual bits here
include CApp
CFLAGS = $(filter-out ${C_NO_FNAMES},${CFLAGS})

Thanks for the suggestion! Sadly it fails, with AMU telling me

AMU: functions nested too deeply while processing 'filter-out' (maximum depth is 64)

I think this is supposed to be the point where I say that a simple per-project MakeFile can be easily modified and does what is necessary without undue complications. ;-)

I think this is supposed to be the point where I say that a simple per-project MakeFile can be easily modified and does what is necessary without undue complications. ;-)

Perhaps… :-)

I’m trying to update the C tutorial that I started a while back, and would therefore prefer to stick with the simplicity of vanilla shared makefiles for now. Personally I’d not even be using the DDE, but I seem to be in a minority on that one. ;-)

AMU [tells me] functions nested too deeply while processing ‘filter-out’

That makes sense now I look how CFLAGS is initially defined (equals, not colon equals) so it’s trying to evaluate it when passed to filter-out, which in turn requires it to run filter-out in order to evaluate it. Circular.

Well it was untested! This, however I have tested, and seems to do what you want:

# COMPONENT, OBJ, and usual bits here
include CApp
C_NO_FNAMES =

ie. just reassign the C_NO_FNAMES to be an empty string so when CFLAGS is evaluated that switch is gone.

That does indeed work – thanks!

I’m fairly sure that I tried reassigning C_NO_FNAMES, but suspect that it was in the wrong place since it was before the include CApp… Perhaps another bit of the Makefile Mist is finally clearing. :-)

Perhaps another bit of the Makefile Mist is finally clearing. :-)

It may seem strange, but that makes my difficulties understanding it all a little less oppressive.

Since others seem to subscribe to the “avoid it” philosophy I suspect they too don’t understand, which is rather where I was coming from in earlier discussions about the need to document this better (at all?)

Pretty much that.

A small MakeFile that does a specific task, or a more powerful system that is opaque and pulls in bits from who knows where to do who knows what…

which is rather where I was coming from in earlier discussions about the need to document this better (at all?)

The official documentation for the AMU makefile syntax/operation does seem a bit lacklustre. However that manual is for a mid-90’s release, and it looks like some of the features talked about here (includes, :=, etc.) were introduced more recently, so maybe at the time of writing those docs were a complete description of the functionality?

In the absence of a full AMU manual you can work out most things by reading the GNU make manual. But since AMU isn’t fully compatible with GNU make we could really do with a full manual for AMU, or at least a checklist of which features from a popular alternate make are/aren’t supported by AMU.

Possibly the latest DDE manual is better than the old one on riscos.com and already contains this (I’m at work so can’t easily check)

A small MakeFile that does a specific task, or a more powerful system that is opaque and pulls in bits from who knows where to do who knows what…

For beginners, who don’t want to do anything more complex than the Shared Makefiles support, they’re ideal: you don’t have to understand what they’re doing beneath the surface. One of the reasons that I chose to use them here was that they made it possible to get a project up and running with full AMU support without knowing how to write a full Makefile.

And if you do wish to know what’s going on underneath, they’re hardly opaque: you just follow the includes… You need to understand Makefile syntax, of course – but if you don’t, you might as well take them on trust as you’re not going to be writing your own…

There’s also a maintenance problem. I’ve recently moved all of my GCCSDK projects across to a standard set of shared Makefiles (of my own devising), because it makes maintenance easier. If something common needs fixing, it only needs fixing in one place and not across dozens of projects which each have very similar Makefiles in them… :-)

This very topic stands as a good example of the potential downside of so embody else’s MakeFile, needing to know to define C_NO_FNAMES to be empty. As opposed to twiddling an -f flag option.
Basic MakeFiles aren’t that difficult, so long as you let AMU do the work. Make just whinges all the time. ;-)

As for CFLAGS = $(filter-out ${C_NO_FNAMES},${CFLAGS}) – OMG what?

Here’s a thought – have you tried aliasing cc to echo out the command line? I’m wondering what exactly is being passed as options. If I build on my Pi1, is it specifying the ARM11 processor, for example? What libraries is it including by default? If TCPIPLibs, which version? What if you want to use _fmapstore (part of ANSILib)? Or DeskLib/OSLib/etc?

(^_^)

Point here is, make your own MakeFile, you’ll know exactly what the options and libraries are, and it can be customised for each application.
I’m scratching my head wondering what sort of MakeFile fail would need all those MakeFiles to be updated. Shouldn’t even be an issue if an add-on library gets moved, it ought to be referred by Path: notation, not an absolute place…

Point here is, make your own MakeFile, you’ll know exactly what the options and libraries are, and it can be customised for each application.

The point here is (comment coming home to roost :P) you’re thinking like a geek.
For all normal people life is too short to be arsing around with the subtleties of Make’s infinite varieties when you can just use the same base for pretty much everything and do an occasional tweak to turn things rather verbose or some such.

Possibly the latest DDE manual is better than the old one on riscos.com and already contains this (I’m at work so can’t easily check)

There is a lot more information in the current manual, but I don’t have time to look into specifics now (I should be on my way to work!)

There is a lot more information in the current manual, but I don’t have time to look into specifics now (I should be on my way to work!)

Meanwhile, I’m now at home, so I can check myself! A quick skim through the AMU appendix suggests that it does cover all of the “new” functionality in sufficient detail. So chances are that it is a complete description of the supported features.

Here’s a thought – have you tried aliasing cc to echo out the command line? I’m wondering what exactly is being passed as options.

amu -v

If I build on my Pi1, is it specifying the ARM11 processor, for example?

Fun fact: If you’re selecting an environment via !Builder then it will set up aliases for cc & objasm which specify the CPU target.

https://www.riscosopen.org/viewer/view/mixed/RiscOS/Library/ToolOptions/APCS-32%2Cfeb?rev=1.13

I’m not sure of the exact reason for this, but it wouldn’t surprise me if it was done this way precisely because of the problem that not every component uses/used the shared makefiles. Unfortunately doing things this way can cause problems, e.g. you can’t easily specify -apcs /vfp to objasm because it conflicts with the setting in the alias.

I’m scratching my head wondering what sort of MakeFile fail would need all those MakeFiles to be updated. Shouldn’t even be an issue if an add-on library gets moved, it ought to be referred by Path: notation, not an absolute place…

In my experience the power of shared makefiles is when you want to make sweeping changes to your toolchain/build pipeline. E.g. switching to a different version of the same compiler (might need to change the flags to silence warnings or maintain compatibility), or switching to a different compiler altogether (compiler flags will be completely different), or if you want to add a new build target to every project which does a specific thing (archive debug symbols, run unit tests, etc.)

Shared makefiles are also pretty useful when you’ve got a team of people working on different projects (with individual people potentially working on multiple projects). Each team member doesn’t need to learn the intricacies of each project-specific makefile (e.g. whether the default target will produce a release or debug build), and for senior/lead programmers the “correctness” of a makefile can easily be ascertained (does it use the shared makefiles? are there any custom flags or build rules which mean we’ll be shipping internal-use-only debug builds of code to customers? etc.)

Of course there are downsides to shared makefiles (they’re an extra dependency you’ll need to distribute if you want to release your source code, they’re an extra source of compatibility issues if they change and break a project, etc.). But on the whole they’re worth it when you want to make sure a group of projects all implement a set of build targets in a consistent manner.

you’re thinking like a geek. […] For all normal people life is too short

You ought to know that the True Path of Geek Enlightenment is laziness. We are geeks not because we have special braincells, but because we look at something and think “what a bother” and try to devise better ways of doing things (where “better” almost invariably means “with less effort”).

Other people, they don’t seem to think like that. When the floor washer machine at work stopped working, the girls on production were like “oh well, can’t be helped” and looked for other ways to do the job. Since I use the machine, and since I didn’t fancy doing my job the long-winded way, I tipped the machine to its side…
…and plugged the battery cable back in.

A small moment of effort meant a morning expending less effort. Simple.

There are, however, some people who are almost capable. They see something that could be simpler. Then they form a committee to discuss it and, well, that’s about as far as it gets.

when you can just use the same base for pretty much everything and do an occasional tweak to turn things rather verbose or some such.

And so we get to this.
Come now.
Do you seriously think I rewrite every single MakeFile from scratch? What a pain in the ass that would be. I just grab one and change the names as applicable.
# Apart from the names and a few other changes – my story’s the same one…
If you’ve seen my MakeFiles (posted here from time to time), I use a macro to build C files (in .c) and assembler files (in .s), so I can simply list all of the object files in each category and let AMU deal with that for itself. I don’t need to rewrite/repeat a dozen “build me” instructions. Why change fifty lines when you can change three?

You ought to know that the True Path of Geek Enlightenment is laziness.

A work colleague once said “I’ve never met anyone who spent so much time and effort on a job while saying they really didn’t want to do it” I replied that he’d missed the final word: “again”
There’s a big collection of scripts at work, cumulative time invested was months, haven’t looked at any of them in the last 5 years and mostly longer. Did put lots of comments in so others could understand and alter them.

I would say Jeffreys explanation covers things – project integration.

If you’ve seen my MakeFiles (posted here from time to time), I use a macro to build C files (in .c) and assembler files (in .s), so I can simply list all of the object files in each category and let AMU deal with that for itself. I don’t need to rewrite/repeat a dozen “build me” instructions.

You’ve then got the build date, SVN revision and/or release version number to evaluate and pass to the compiler, assembler, tokeniser or help builder for baking into the Info windows or *Help output. The package version details to work out. RISC OS menus to build from source files. StrongHelp, text, HTML and DDE versions of the manual to build from the manual source file; along with the top-level ReadMe file to construct from them. The BASIC !Help script to tokenise from source.

If you’re targeting a release (be it full or test build), you’ve then got the release archive and source code archive to construct. Plus the RiscPkg package to construct.

That lot’s just from a quick scan of my C application common makefile.

Why change fifty lines when you can change three?

Exactly. That’s why it’s helpful to abstract all of the common stuff into a single shared file!

I think we’re drifting a little from the point. Using a DDE Shared makefile, we can make an application using just

# Makefile for Example App

COMPONENT = ExampleApp

OBJS = main ibar repbox

CINCLUDES = -IC:,OSLib:,SFLib:
LIBS = SFLib:o.SFLib OSLib:o.OSLib32

include CApp

C_NO_FNAMES =

# Dynamic dependencies:

(to grab an example that uses our new-found knowledge from this thread). To me, this is a lot easier to learn to use than a full-blown makefile – because I don’t need to know how it does what it does behind that include line. If users wish to explore further, or write their own makefiles, there’s nothing stopping them. For a lot of applications, the above will let those new to the DDE just get on with the interesting stuff.