irix 6.5.30, mipspro 7.4.x, gnu make 3.8.x, samba 400tp4. ------------------------- using 'gmake -j [n]' is ignored. it's always only using one cpu at a time!
I think we have parallel builds disabled, due to depenencey issues in the makefile, but I'll reassign to our build master and check...
(In reply to comment #1) > I think we have parallel builds disabled, due to depenencey issues in the > makefile, but I'll reassign to our build master and check... > thanks, would highly appreciate this. especially since v4 is much bigger than 3.0.x. the only rub i noticed in earlier version is that the initial headers like proto.h have to be made one after another or it dies. as soon as they're done all went fine using parallel.
Parallel builds are blocked by the fact that we don't have proper dependencies in the Makefile at the moment. The only way to have proper dependencies is autogenerating them. However, that plays silly games with our automatic header generation code as proper rules will trigger regenerating the prototype headers whenever one of the C files it is generated from changes (which, in turn will cause other C files to be regenerated), etc. For this reason, the original automatic dependencies code has been disabled. At some point we had a hack that didn't write the new prototype header if it hadn't changed. However, that causes make to always think that particular header is out-of-date and attempt to regenerate it. It very much looks like this bug can't be fixed properly without switching to some make alternative that doesn't rely on file change timestamps.
well no offence but that's a joke. samba ain't one of these backyard apps and plays an important role in many infrastructures. looking at v4 i see gtk2 as a dep for swat2 - excuse me? the compiled and stripped app has over 200mb without swat - what? and to be a real pita jobserver is turned off, argh :-) i don't know about your goals for v4 but i guess it's still supposed to be a server and not some 'ubuntu-gnome-toy' ...
the swat from samba4 doesn't in any way depend on gtk2. If you have suggestions on how to support the jobserver while not causing a complete rebuild of Samba when a single c file changes with a standard make, we're happy to look at it.
(In reply to comment #5) > the swat from samba4 doesn't in any way depend on gtk2. iirc it's the config gui. anyway a specific part does but that's not a big deal as long as it can be disabled via configure. > > If you have suggestions on how to support the jobserver while not causing a > complete rebuild of Samba when a single c file changes with a standard make, > we're happy to look at it. > i'd love to but since i'm not exactly a coder i'd have to spent a serious amount of time for that. however how did you do it before v4? it always worked like a charm!
> (In reply to comment #5) > > the swat from samba4 doesn't in any way depend on gtk2. > iirc it's the config gui. > anyway a specific part does but that's not a big deal as long as it can be > disabled via configure. there are two different interfaces: one is the new swat (http-based, like it was previously), the other is the gtk+ stuff. > > If you have suggestions on how to support the jobserver while not causing a > > complete rebuild of Samba when a single c file changes with a standard make, > > we're happy to look at it. > i'd love to but since i'm not exactly a coder i'd have to spent a serious > amount of time for that. > however how did you do it before v4? it always worked like a charm! before v4 there wasn't that much autogenerated code. the dependencies are much more complicated now. 'make proto' won't just work because some headers require specific C files to be generated, which requires some compiler to be built, which needs prototypes, etc. I guess we could do a two-stage approach where the first stage wouldn't support parallel builds. That would build things like compile_et, asn1_compile, etc. The second stage could then be built in parallel.
(In reply to comment #7) > there are two different interfaces: one is the new swat (http-based, like it > was previously), the other is the gtk+ stuff. yes that's what i meant. > I guess we could do a two-stage approach where the first stage wouldn't support > parallel builds. That would build things like compile_et, asn1_compile, etc. > The second stage could then be built in parallel. sounds very good :-)
Maybe this will be fixed by the new buildsystem..
How up-to-date is this issue?
(In reply to comment #10) > How up-to-date is this issue? Still valid, no news.
Update title (remove version number).
Jelmer, does the new python build infrastructure change something?
Update: the gmake build system doesn't and won't support this. But our new WAF-based one (just landed in the "master" branch - and will be available in the upcoming releases) finally supports parallel building. Please try it out (start it using "./autogen-waf.sh")! This should be enough to mark this bug finally as "FIXED".