On Tue, 25 Mar 2014 00:09:21 +0100 Johan Engelen <jbc.engelen@...2592...> wrote:
Hi Isobel, Some quick feedback after a discussion with su_v on IRC. We think we should keep the Makefile_insert files per folder, making it much easier to maintain the list of files to be compiled, instead of having all lists in one huge file.
Dear Johan,
Perhaps su_v missed the comments above the file lists... It was not my intention to list all the files in one place (su_v's right it is cumbersome); it was merely convenient for me to do so whilst I was discovering what the plethora of Makefile.am's and Makefile_insert's actually did. Nevertheless, thank you for the comment. That's 2 votes for hierarchical lists.
Now that the topic has been raised, it might be time to talk about the way source code might be organised in future, and this in turn depends upon inkscape's included libraries.
At the moment the Makefile just lists all the files required by the libraries. This is because I must list all the files in the source distribution. Basically, the top 3/4 of the Makefile is a list of files to add to dist_files. Therefore it would make sense to write the Makefile like this:
- Top of the Makefile down to the comment above cxxtest_src to be kept as it is now - Follow this by a series of include statements for the sub-makefiles - After win32_srcs the action should return to the top-level Makefile
This would necessitate breaking up the naughty_files macro into lots of entries, once per included makefile.
My feeling is all the libraries apart from libinkscape should have a single inserted makefile per library rather than one per directory. The lists are short enough to do this, and there is no particular advantage to having a deep hierarchy for just a handful of files. Remember, when we use just a single makefile for the whole build, it is meaningless to cd ; edit file.cpp ; make - the make must be executed from the top level alone (either directly or with make -C).
Libinkscape is a special case; it's file list is so big it is cumbersome to do this all in one. I think one file per directory is probably the way to go. I will, however, make just one further point. If the files in those sub-directories really are logically grouped together, perhaps there is a case for separating them into their own archives. I say this because if we adopt incremental linking, this kind of change could considerably speed up a link when only a few files have changed. Without separating them into "sub-libraries", the final link will always take a long time.
Like I said, this is for the future, but I can see a case for moving groups of files into a flatter directory structure to *uniformly* support things like the rules for building libraries, the SEL macros and other debugging niceties. The reason I put all the files into one big list was I didn't want to stir up any bad feelings right at the start... particularly as I don't have any strong feelings about it myself.
When I've managed to get bazaar working I'll try out a few schemes to see what works.
There is another gotcha with included makefiles - evaluation order. It is tempting where included makefiles are split into separate files to think of them in the same way as hierarchically-executed, self-contained Makefiles. They are not the same thing at all. As I stated in my comments, macros must be fully-formed before the rules can use them properly. I can adopt two approaches to this problem:
- ignore it and just put a comment that rules are not permitted in included makefiles at the top of every included makefile, or - adopt the phased inclusion system I used in my own projects.
I prefer the latter approach because it is much more flexible and has fewer surprises. It is an approach I've been using extensively for *cough* years on what must by now be getting on for a 10 million-line hand-written "makefile" I use for my O/S builds. I kid ye not.
Where I am not in favour of all this hierarchical stuff is in the data installation stuff. There is too much temptation to place rules in amongst the macros and get into a right mess with the $(eval)s. It can be done, but it needs care; something which might not be apparent to the make novice. I'd prefer to concentrate on the CPP files first and I can address the data files when I deal with system testing.
As to the nature of the file lists themselves, for the sake of compactness I have written them like this:
libcola_src= \ $(addprefix src/libcola/, a.cpp b.h ...... )
and I've even included my pretty-printer in the code drop. However, I'm not particularly in favour of this. I'm all for cutesy lists but I think it could turn into a dog's dinner quite quickly. It's much easier to understand a diff if it lists just one file per line.
As to the use of $(addprefix), I'm very reluctant to get rid of it. It makes lists more compact. With proper indentation it's function is as clear as day, but more importantly, it allows us to use the += syntax to augment the macros without a care in the world.
What do you think?
Yours,
Is.