Right now, our moz.build migration is simply porting all the Makefile variables directly to moz.build files without thinking about how to represent them in moz.build. So I've given some thought to how we should represent them in the idealized setting, and what I've come up with is this: make_binary(name, [The name of the binary minus the suffix/prefix, e.g. firefox, xul, etc.] type=program|static|shared, [.exe, .a. or .so] sources=[], [List of .cpp/.c/.asm/.mm/.s/etc. files that go into the library] host=True|False, [Are we building this for the host or for the target?] sharedlibs=[], [Static libraries to link in] extraflags=[], [Extra flags to link] enable_pgo=True|False [Should MSVC PGO this library or not?] ) This has a magic part to it which requires an example. Suppose I have two moz.build files, src and build. In src/moz.build, I can say: make_binary('xul', sources=['a.cpp', 'b.cpp'], extraflags=['-lhostlib']) While in build/moz.build, I can say: make_binary('xul', type='shared', sources=['master.cpp']) In this scenario, moz.build would be smart enough to figure out the following: 1. In the directory traversal, src/ will be traversed after build/ (say, src/ is in PARALLEL_DIRS and build/ in DIRS--putting them both in PARALLEL_DIRS is not sufficient). 2. Therefore, the library should be linked when making in build/; src/ will produce a fake static library which build/ uses to link the library. 3. The extra flags of src/moz.build are merged with those in build/moz.build. 4. 'xul' is a hardcoded magic name which also sets LIBXUL_LIBRARY and MOZILLA_INTERNAL_API and maybe several other variables, as well as knowing to generate 'XUL' on mac instead of 'xul' (This is effectively hardcoded into our current build system anyways). This is basically dependent on moving the brunt of our code into moz.build, particularly *SRCS and the LIBRARY stuff. Thoughts?

sources will sniff file extensions?

Yes, as suggested in https://bugzilla.mozilla.org/show_bug.cgi?id=864774#c48.

What does this change buy us? I'm missing some context as to why this is idealized over the current form. Would other parts of the build also be turned into functions? (EXPORTS, XPIDL_SOURCES, PP_TARGETS, etc).

I don't get the build vs. src magic. That being said, i'm not a fan of the function-type declaration. Because for sources or flags that are conditional, you then need a temporary variable, and that makes things more confusing to read. I'd very much prefer sources, flags, etc. to be declared as member variables of some instance, e.g. xul = Library() xul.sources = [ 'a.cpp' ] if config['foo']: xul.sources += [ 'b.cpp' ]

(In reply to Mike Hommey (high latency until June 25) [:glandium] from comment #4) > I don't get the build vs. src magic. I probably didn't do a good job explaining it, but the overarching idea is that instead of having every source directory (e.g., netwerk/mime) define a static library name and then declare in toolkit/library that said static library is included in libxul, the source directories themselves declare that their code goes into libxul and have moz.build work out what needs to be done to make it work. > That being said, i'm not a fan of the function-type declaration. Because for > sources or flags that are conditional, you then need a temporary variable, > and that makes things more confusing to read. You can simply just call the function again within the conditional and things should just work (maybe add_to_binary is a better name than make_binary). I'm not too wedded to the function design, but the key points I want to keep are the following: 1. You can add to the same library from multiple directories and things will just work. 2. Sources are sniffed by their filetype, not explicit CSRCS/CPPSRCS/CMM/etc. 3. Sources are directly associated with the output library/executable they go to, not a static list. [This would help eliminate things like GTEST_SRCS or SIMPLE_PROGRAMS]. 4. Magic variables that affect things like DEFINES (such as MOZILLA_INTERNAL_API or LIBXUL_LIBRARY) should be associated with the library object and Just Work. 5. The infrastructure is basically the same if you're building for the host or for the target, or if you're building a static/shared/program library. (In reply to Michael Shal [:mshal] from comment #3) > What does this change buy us? I'm missing some context as to why this is > idealized over the current form. Would other parts of the build also be > turned into functions? (EXPORTS, XPIDL_SOURCES, PP_TARGETS, etc). The biggest change, and most useful, is that source files become directly associated with the things they link into instead of requiring everything in the directory to go into the same binary and hacking extra variables where that doesn't work (i.e., GTEST_SRCS, SIMPLE_PROGRAMS). I used the function notation mostly because the multiple-directories-just-work part felt like it made more sense as a function (a la add_tier_dirs).

jcranmer: what you've proposed is largely what I envision as the end state. The main difference is I agree with glandium that an object-oriented interface is superior to a single unified function. Although, in the end they accomplish the same thing. We'll likely borrow an ontology for declaring binaries from something like cmake or GYP and add Mozilla-isms as appropriate.

I went through rules.mk and config.mk and started documenting things at https://etherpad.mozilla.org/build-defining-binaries Attached is the beginning of an implementation for this. Maybe some here will pick this up and finish it. Even if the initial implementation simply writes out pass-thru variables into backend.mk, I'll consider that an improvement over what we have today with disparate variables for everything.