On Sat, 22 Mar 2014 19:16:29 +0100 Johan Engelen <jbc.engelen@...2592...> wrote:

Hi Isobel, Could you make a branch instead? It's prohibitively painful to use the diff-files you posted on Windows.

Dear Johan,

I am sorry I have made things difficult for you. That was not my intention. At this stage, I'm afraid I cannot make a bazaar branch because whilst I am now able to collect tar files of named bazaar revisions from the bazaar browser on the web, I am unable to access bazaar itself.

I would much prefer to work without my hands tied behind my back, but my web browser seems to spit feathers on the OpenID stuff that launchpad uses. I think it might be something to do with my web proxies, but frankly it's beyond me. I suspect that if someone (you, perhaps) could set up an account for me on launchpad and emailed me the password (or whatever it is bazaar uses), or even just explain the process in more detail than the notes on the wiki do, I could get it going. I'm champing at the bit, but I don't want to be a burden.

Until then might I suggest that I update my makefiles to the current trunk, titivate them a little as per my comments on the other threads and submit them again. This would make the diffs smaller and more meaningful. However, any alterations I submit are necessarily going to involve deleting quite a lot of files, replacing them with three or four new files, and patching a half-dozen more.

At this stage, perhaps all that is called-for is for you to take a look at the new Makefiles in overview. I am happy to post the Makefiles or (annotated?) snippets from them in a more digestible form. There are three important files: Makefile, config.make.in and settings.make.example together with some piffling changes to config.h.in and some pods. The only other changes are to INSTALL where I add some descriptive waffle and to configure.ac where I move things around a bit to split out the build options. You name it and I'll do it.

Regards,

Is.

PS. I'm impressed by how far you've got with -Werror etc. and am keen to help you polish this off.

Hi, I can't help you with configuring your proxy, but I'd suggest create your branch the following way: mkdir inkscape cd inkscape bzr init-repo . bzr checkout lp:inkscape trunk bzr branch lp:inkscape your_branch bzr push lp:~your_login/inkscape/your_branch

This gives you a shared repository where you always have got a copy of the current trunk as well as your own branch. To merge from trunk you'd do a cd trunk bzr update cd ../your_branch bzr merge ../trunk

Using "branch" instead of "checkout" allows you to commit even when you're offline (and reverting commits and the like).

Regards, Markus

-----Ursprüngliche Nachricht----- Von: Isobel Knowles [mailto:ik5@...2950...] Gesendet: Sonntag, 23. März 2014 20:41 An: Johan Engelen Cc: inkscape-devel@lists.sourceforge.net Betreff: Re: [Inkscape-devel] Building with make

On Sat, 22 Mar 2014 23:26:18 +0000 Isobel Knowles <ik5@...2950...> wrote:

On Sat, 22 Mar 2014 19:16:29 +0100 Johan Engelen <jbc.engelen@...2592...> wrote:

...

Hi Isobel, Could you make a branch instead? It's prohibitively painful to use the diff-files you posted on Windows.

Dear Johan,

I am sorry I have made things difficult for you. That was not my intention. At this stage, I'm afraid I cannot make a bazaar branch because whilst I am now able to collect tar files of named bazaar revisions from the bazaar browser on the web, I am unable to access bazaar itself.

I would much prefer to work without my hands tied behind my back, but my web browser seems to spit feathers on the OpenID stuff that launchpad uses. I think it might be something to do with my web proxies, but frankly it's beyond me. I suspect that if someone (you, perhaps) could set up an account for me on launchpad and emailed me the password (or whatever it is bazaar uses), or even just explain the process in more detail than the notes on the wiki do, I could get it going. I'm champing at the bit, but I don't want to be a burden.

Dear Johan and Bazaar gurus,

You can call off the dogs! I've finally managed to create a launchpad account! Amazingly, I needed to compile dozens of ffox dependencies with -O0 but glib with -O3 before ffox would show the create account page. I've come across some abominable web sites in recent years, but never have I experienced anything that's prodded so many browser bugs in one go. It's bazaar.

I've managed to perform a bzr launchpad-login by setting http[s]_proxy, but I'm stumped at the next step:

# bzr checkout lp:inkscape ssh: connect to host bazaar.launchpad.net port 22: Network is unreachable ConnectionReset reading response for 'BzrDir.open_2.1', retrying ssh: connect to host bazaar.launchpad.net port 22: Network is unreachable bzr: ERROR: Connection closed: Unexpected end of message. Please check connectivity and permissions, and report a bug if problems persist. # _

Yours,

Is.

---------------------------------------------------------------------------- -- Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

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.