Makefile optimizations -> move away from recursive make?

rebroad commented at 4:16 am on April 1, 2014: contributor

Would it be possible to have the Makefile such that one can compile the minimum necessary to create the bitcoin-qt binary?

laanwj commented at 6:29 am on April 1, 2014: member

I’d say:

0./autogen.sh
1./configure --without-daemon --without-cli --disable-tests
2make

luke-jr commented at 6:31 am on April 1, 2014: member

or

0make src/qt/bitcoin-qt

rebroad commented at 0:40 am on April 3, 2014: contributor

@luke-jr Firstly, that doesn’t seem to work if I modify a file, e.g. main.cpp, the updated version isn’t used if I don’t “make clean” first. Secondly, if I do “make clean” first, it doesn’t work and gives “make[1]: *** No rule to make target ../../src/libbitcoin_server.a', needed bybitcoin-qt’. Stop.”

(How do I “backslash” the special characters on github so it doesn’t think I’m meaning to change the formatting?)

laanwj commented at 6:44 am on April 3, 2014: member

That’s what you get with recursive makefiles: dependency tracking over directories is as good as non-existent.

laanwj added the label Build system on Apr 3, 2014

rebroad commented at 3:31 am on April 6, 2014: contributor

Ok, so how can we fix this? Something like this perhaps? http://stackoverflow.com/questions/2374863/makefile-build-directory-and-dependencies-list

Also, http://aegis.sourceforge.net/auug97.pdf

rebroad renamed this:
~~Possible to "make bitcoin-qt"?~~
Makefile optimizations -> move away from recursive make?
on Apr 6, 2014

laanwj commented at 5:56 am on April 7, 2014: member

No idea. I am not a autotools guru, and build system issues are stacking up every day. It would be great if you could fix this one yourself.

rebroad commented at 7:29 am on April 7, 2014: contributor

Perhaps the person who introduced the autotools ought to take some responsibility for the mess they seem to have created!

laanwj commented at 7:33 am on April 7, 2014: member

Please be respectful. That person (@theuni) has no blame for that. He initially made the makefile non-recursive, but some people insisted on recursive makefiles. This is what they got. Scratch your own itches or bugger off.

laanwj closed this on Apr 7, 2014

sipa commented at 7:33 am on April 7, 2014: member

Ironically, it was not Cory who wanted recursive makefiles…

rebroad commented at 7:38 am on April 7, 2014: contributor

@laanwj I am being respectful. Telling people to “bugger off” isn’t respectful, IMHO.

rebroad commented at 7:39 am on April 7, 2014: contributor

Ok, so can we rewind the commits that introduced recursion. Also, please re-open this issue, as it hasn’t been fixed.

theuni commented at 3:23 pm on April 7, 2014: member

While the tone here was not exactly productive, I do agree that it’s an issue. I did not want recursive makefiles because they tend to turn into dependency spaghetti, but some argued against a monolithic one when I was doing the autotools port, so I chose to compromise on that for the sake of the larger goal. Now, let’s move on…

Now we have some spaghetti. If the majority can agree that non-recursive would be cleaner now, I could be convinced to do the work.

The other main change that’s necessary (as @laanwj saw elsewhere) is that libtool would be needed to do this cleanly. I chose to avoid libtool for the initial port since it can be a pain to use on some systems (win32). Since there’s been very little outcry about not building on win32, I think it’s probably safe to introduce this dependency now.

theuni commented at 3:28 pm on April 7, 2014: member

@laanwj As for the build-system issues stacking up, I haven’t seen them. Would you mind cc’ing me as you see them, and I’ll subscribe myself in a few places so that I see them better?

laanwj commented at 3:50 pm on April 7, 2014: member

@theuni I’m not sure a non-recursive makefile would be better in general. It would avoid this problem, but there may be other drawbacks.

As for other build system issues, see: https://github.com/bitcoin/bitcoin/issues?direction=desc&labels=Build+system&page=1&sort=created&state=open

theuni commented at 4:03 pm on April 7, 2014: member

@laanwj There are only two major drawbacks that I can think of:

It’s less clear how to build a single thing rather than everything. For example, “cd qt; make” goes away, instead you’d use something like “make qt” from the top. This could be faked by adding stub makefiles at those levels that just do “make -C ../ [target]”
Likely to end up with one really huge Makefile.am. If we’re careful, this could be split into some include files as we currently do. From a non-maintainer POV, this is a non-issue.

What other drawbacks do you have in mind?

laanwj commented at 4:45 pm on April 7, 2014: member

@theuni Right, both of those issues can be worked around. Stub makefiles as well as include files per directory could make the situation similar to now, without resulting in one big hairy makefile. I was primarily afraid that this will make things more complex (to add new files, for example, or in general to understand what happens). But I’m not sure that’s true.

theuni commented at 5:34 pm on April 7, 2014: member

@laanwj In that regard, I don’t think much changes. All the same rules still apply, they just might apply in a different file.

If you’re up for it, I could do up a dumb version for the sake of discussion, maybe just bitcoin-cli+tests or so.

sidhujag referenced this in commit b191c6c5ee on Feb 17, 2021

MarcoFalke locked this on Sep 8, 2021

Makefile optimizations -> move away from recursive make? #3989