The MAME and MESS merge

[u-man]

Yeah, I know, right now Miodrag Milanovic is creating new scripts for custom builds with specified drivers. I hope nothing will happen till 163 

This..... :

u-man: "Of all the news, this one is the worst. If i understand that correctly, than with version 0164, there will be no more a option to keep MAME and MESS seperated, while compiling... am i right?"

R.Belmont: "We are instead going to have a more flexible build system where you can do single-driver builds for fast development where it should automatically figure out what files are necessary. For instance, "make SUBTARGET=vaportrx DRIVERS=src/mame/drivers/seattle.c" will make a MAME build that only plays vaportrx. I'm not yet clear if there'll be some way to make this do something like the existing split builds, but in general those aren't popular with the devs and single-driver builds are (they make the compile/link/test cycle much, much faster)."

which brings me to the next question... is GroovyMame supporting the MESS merge? and if so, will there be options, to seperate MAME from MESS?

[Calamity]

which brings me to the next question... is GroovyMame supporting the MESS merge? and if so, will there be options, to seperate MAME from MESS?

Not only I support the merge, GroovyUME was one of the firsts combined builds available (if not the first one) back in 2012. For me the fact that the merge became official simply means that I don't have to mantain two builds anymore which is a relief. I guess users who are concerned about having the home systems included in the executable will come out with a way to arrange a custom build.

[haynor666]

u-man: "Of all the news, this one is the worst. If i understand that correctly, than with version 0164, there will be no more a option to keep MAME and MESS seperated, while compiling... am i right?"

R.Belmont: "We are instead going to have a more flexible build system where you can do single-driver builds for fast development where it should automatically figure out what files are necessary. For instance, "make SUBTARGET=vaportrx DRIVERS=src/mame/drivers/seattle.c" will make a MAME build that only plays vaportrx. I'm not yet clear if there'll be some way to make this do something like the existing split builds, but in general those aren't popular with the devs and single-driver builds are (they make the compile/link/test cycle much, much faster)."

It's not a problem personally as I'm going to build full groovymame, MAMEUI is almost ready for this too, question is what's going will be with MAMEFX.

[u-man]

I guess users who are concerned about having the home systems included in the executable will come out with a way to arrange a custom build.

I hope that too

[u-man]

It's not a problem personally as I'm going to build full groovymame, MAMEUI is almost ready for this too, question is what's going will be with MAMEFX.

this is indeed a problem. it seems that UIFX will need to rely on custom lists by 3rd developers, which is not nice as it will trail behind other releases .
Other than that, are some frontends that will also have similar problems.... time will tell.
what really upsets me, is the force how this whole process was done and why they will remove the option for split-compiles?
in case of groovymame, i really dont see the benefit of this merge, because it is mainly used in cabs and you can barely handle those computer / console games on a cab or the thing to play handheld games on a 28" screen, is a little bit oversized.

but ok, thats how it is and will be .