'm68340DMA’ was not declared in this scope

[katananja]

GIT ver. 6435f7b004..8bfcc5c50e Debian 9 x64

Compiling src/devices/machine/68340dma.cpp...
In file included from ../../../../../3rdparty/softfloat/mamesf.h:24:0,
                 from ../../../../../3rdparty/softfloat/milieu.h:36,
                 from ../../../../../src/devices/cpu/m68000/m68000.h:11,
                 from ../../../../../src/devices/machine/68340.h:9,
                 from ../../../../../src/devices/machine/68340dma.cpp:6:
../../../../../src/devices/machine/68340dma.cpp: In member function ‘u32 m68340_cpu_device::m68340_internal_dma_r(address_space&, offs_t, u32)’:
../../../../../src/devices/machine/68340dma.cpp:11:9: error: ‘m68340DMA’ was not declared in this scope
  assert(m68340DMA);
         ^
../../../../../src/devices/machine/68340dma.cpp: In member function ‘void m68340_cpu_device::m68340_internal_dma_w(address_space&, offs_t, u32, u32)’:
../../../../../src/devices/machine/68340dma.cpp:22:9: error: ‘m68340DMA’ was not declared in this scope
  assert(m68340DMA);
         ^
optional.make:16677: recipe for target '../../../../linux_gcc/obj/x64/Debug/src/devices/machine/68340dma.o' failed
make[2]: *** [../../../../linux_gcc/obj/x64/Debug/src/devices/machine/68340dma.o] Error 1
Makefile:91: recipe for target 'optional' failed
make[1]: *** [optional] Error 2
makefile:1243: recipe for target 'linux_x64' failed
make: *** [linux_x64] Error 2

Tiny version is ok.

Does this "tiny" test is really effective? Why not compile a full version as a base, then compile just the changed driver or machine? It should fail if something is wrong. Like before, tiny did not reflect compilation errors. Maybe something like: for f in $(find . -name *.[oa]); do rm -f $f; done && make SOURCES=src/devices/something/something.cpp REGENIE=1

I think this is much less time consuming and could reflect real tests over the changed sources instead of "tiny".

Thanks.

[galibert]

Because a CI creates a new (virtual) machine for each compile, there's nothing kept.

Because how will you choose "something" from the commit itself?

OG.

On Thu, Dec 14, 2017 at 1:05 AM, Wellington Uemura <notifications@github.com

wrote:

GIT ver. 6435f7b https://github.com/mamedev/mame/commit/6435f7b004ad07842e9a4af20bfacdf60b67e215 ..8bfcc5c https://github.com/mamedev/mame/commit/8bfcc5c50ed11edb03481cee105696ff874f63d2 Debian 9 x64

Compiling src/devices/machine/68340dma.cpp... In file included from ../../../../../3rdparty/softfloat/mamesf.h:24:0, from ../../../../../3rdparty/softfloat/milieu.h:36, from ../../../../../src/devices/cpu/m68000/m68000.h:11, from ../../../../../src/devices/machine/68340.h:9, from ../../../../../src/devices/machine/68340dma.cpp:6: ../../../../../src/devices/machine/68340dma.cpp: In member function ‘u32 m68340_cpu_device::m68340_internal_dma_r(address_space&, offs_t, u32)’: ../../../../../src/devices/machine/68340dma.cpp:11:9: error: ‘m68340DMA’ was not declared in this scope assert(m68340DMA); ^ ../../../../../src/devices/machine/68340dma.cpp: In member function ‘void m68340_cpu_device::m68340_internal_dma_w(address_space&, offs_t, u32, u32)’: ../../../../../src/devices/machine/68340dma.cpp:22:9: error: ‘m68340DMA’ was not declared in this scope assert(m68340DMA); ^ optional.make:16677: recipe for target '../../../../linux_gcc/obj/x64/Debug/src/devices/machine/68340dma.o' failed make[2]: [../../../../linux_gcc/obj/x64/Debug/src/devices/machine/68340dma.o] Error 1 Makefile:91: recipe for target 'optional' failed make[1]: [optional] Error 2 makefile:1243: recipe for target 'linux_x64' failed make: *** [linux_x64] Error 2

Tiny version is ok.

This "tiny" test is really effective? Why not compile a full version as a base, then compile just the changed driver or machine? Maybe something like: for f in $(find . -name *.[oa]); do rm -f $f; done && make SOURCES=src/devices/something/something.cpp REGENIE=1

I think this is much less time consuming and could reflect real tests over the changed sources instead of "tiny".

Thanks.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/mamedev/mame/issues/2933, or mute the thread https://github.com/notifications/unsubscribe-auth/AI0i8WRE48tg-4aJ4MNhUTiARR_JD7v3ks5tAGZXgaJpZM4RBXC4 .

[katananja]

How? By collecting what was committed like "src/mame/drivers/hh_sm510.cpp" or "hh_sm510.cpp" in to a queue and organize a script to build just what was changed, I don't know. echo $(filter commit fa8bf5e and extract source path or source file name) > queue && read queue and define a variable; do make SOURCES=$(fill in the variable) REGENIE=1; if error=1 BUSTED else OK.

Take a fully compiled MAME structure with all the objects and archives but the final binary, than you take "hh_sm510.cpp" for example and try to build and link a final binary with it. The logic will be to take "hh_sm510.cpp", identify the related objects and archives, rename then to something else and run the scripts to compile a new object/archive against the template and to link a final binary.

If it pass, apply commit, if not, alert the developer, display an error (etc), I don't know how this git process work, sorry, then rename back the previous working objects and archives so the next commit in queue can go on.

This might save resources by avoiding the build of "tiny" over and over again, we know that "tiny" doesn't reflect sources changes. It saves time since it will compile and link just the changes, taking only seconds instead of minutes making the test process much more fast and efficient.

[galibert]

That only works for changes to files in drivers, what about all the rest?

OG.

On Thu, Dec 14, 2017 at 10:45 AM, Wellington Uemura < notifications@github.com> wrote:

How? By collecting what was committed like "src/mame/drivers/hh_sm510.cpp" or "hh_sm510.cpp" in to a queue and organize a script to build just what was changed, I don't know. echo $(filter commit fa8bf5e and extract source path) > queue && read queue and define a variable; do make SOURCES=$(fill in the variable) REGENIE=1; if error =1 BUSTED else OK.

Take a fully compiled MAME structure with all the objects and archives but the final binary, than you take "hh_sm510.cpp" for example and try to build and link a final binary with it. The logic will be to take "hh_sm510.cpp", identify the related objects and archives, rename then to something else and run the scripts to compile a new object/archive against the template and to link a final binary.

If it pass, apply commit, if not, alert the developer, display an error (etc), I don't know how this git process work, sorry, then rename back the previous working objects and archives so the next commit in queue can go on.

This might save resources by avoiding the build of "tiny" over and over again, we know that "tiny" doesn't reflect sources changes. It saves time since it will compile and link just the changes, taking only seconds instead of minutes making the test process much more fast and efficient.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/mamedev/mame/issues/2933#issuecomment-351660047, or mute the thread https://github.com/notifications/unsubscribe-auth/AI0i8QJ7Ut26Y-rKrXkg7LDyllbBuFHXks5tAO42gaJpZM4RBXC4 .

[katananja]

Please define what the rest is so I can elaborate better about it. Sorry, I'm not a developer.

[PeterBortas]

Because a CI creates a new (virtual) machine for each compile, there's nothing kept.

Travis permits caching between sessions. I tried the trivial(1) version of that, enabling ccache, 2 weeks ago. But that was not enough to build a complete Mame even if nothing changed in the source between runs.

It is possible to cache arbitrary files specified by cache-directory directives in travis.yml, so it might me possible to do something more involved that works as long as no central .h files have changed.

1. Not quite as trivial as one would expect perhaps. If you just let a build run into the timelimit then nothing in the cache will be saved. You need to end it before the timelimit so that the VM has some time left to save the cache. See https://github.com/valgrind/mame/blob/master/.travis.yml for how I hacked around that.

[galibert]

The rest is every source file that is is not in the src/mame/drivers subdirectory. What such a file is changed (which is 99% of commits out there), what do you put in the SOURCES= line?

OG.

On Thu, Dec 14, 2017 at 2:27 PM, Wellington Uemura <notifications@github.com

wrote:

Please define what the rest is so I can elaborate better about it. Sorry, I'm not a developer.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/mamedev/mame/issues/2933#issuecomment-351710225, or mute the thread https://github.com/notifications/unsubscribe-auth/AI0i8RLhccRJ1ruYzeFTmNWVioqkA79sks5tASIugaJpZM4RBXC4 .

[katananja]

The files compiled outside "SOURCES=" can work the exact same way, by doing routines inside the server responsible to run this tests, it don't need to be inside MAME sources. The files that can be done with "SOURCES=" we use it, others we do something else.

Suppose mameopts.cpp change inside the frontend folder, create a script or routine necessary to first, identify where the file source belong to, easy to do filtering the commit, run the script responsible to compile all the files inside that folder and try to link a final binary, if something is wrong it will return a error in seconds.

Same will happen with a .h file, if a declaration is wrong it will return an error in seconds using the same principle the moment that something will be linked together. Compile everything and link nothing, try to compile the changed source file, link a final binary, if something goes wrong we will know it in seconds.

[galibert]

The folders are not compilable as-is. Or to be more precise, they're not linkable.

As for .h, if a define is wrong it will be noticed only where it is used. And that's not trivial at all to track.

Seriously, trying to find out what to test after a change is a nontrivial task Tafoid has worked a lot on and is still doing in large part manually. Which doesn't work in a pure automation context, obviously.

In RB's immortal words: "if it was easy, we'd have done it already".

OG.

On Thu, Dec 14, 2017 at 3:10 PM, Wellington Uemura <notifications@github.com

wrote:

The files compiled outside "SOURCES=" can work the exact same way, by doing routines inside the server responsible to run this tests, it don't need to be inside MAME sources. The files that can be done with "SOURCES=" we use it, others we do something else.

Suppose mameopts.cpp change inside the frontend folder, create a script or routine necessary to first, identify where the file source belong to, easy to do filtering the commit, run the script responsible to compile all the files inside that folder and try to link a final binary, if something is wrong it will return a error in seconds.

Same will happen with a .h file, if a declaration is wrong it will return an error in seconds using the same principle the moment that something will be linked together.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/mamedev/mame/issues/2933#issuecomment-351720838, or mute the thread https://github.com/notifications/unsubscribe-auth/AI0i8fH_dNCJvBJ096tdNXx-uD43lj1mks5tASw4gaJpZM4RBXC4 .

[katananja]

The folders was an example, again, I'm not a developer to use the proper words to describe it, this files are gonna be used to build a final binary some way or another, by linking, I don't know.

The suggestion is an easy logic, it doesn't mean it will be easy to construct and organize it, I don't know, but once in place everything will be more efficient. Sorry if I don't have the technical knowledge to describe it better.

Since I have nothing to do with development I can look things outside the box, let's put it this way. Run make to build the full source, the server identify a commit in the png.cpp file for example, make the server rename the file and run make: mv ./build/mingw-gcc/obj/x64/Debug/src/lib/util/png.o to ./build/mingw-gcc/obj/x64/Debug/src/lib/util/_png.o

Test the commit:

time make
GCC 6.3.0 detected
Compiling src/lib/util/png.cpp...
Archiving libutils.a...
Linking mame64d.exe...

real    1m26,840s
user    1m23,584s
sys 0m3,652s

Ok? Than keep the new libutils.a, png.o, delete the final binary and run the next test.

To me is already working, this was the last commit: https://github.com/mamedev/mame/commit/b0b96416eb8685ce9948aa80882e960938c95bca

Something about "68307.cpp"

find . -name 68307.*
./build/mingw-gcc/obj/x64/Debug/src/devices/machine/68307.o
./build/mingw-gcc/obj/x64/Debug/src/devices/machine/68307.d
./src/devices/machine/68307.h
./src/devices/machine/68307.cpp

mv ./build/mingw-gcc/obj/x64/Debug/src/devices/machine/68307.o ./build/mingw-gcc/obj/x64/Debug/src/devices/machine/_68307.o
time make
GCC 6.3.0 detected
Compiling src/devices/machine/68307.cpp...
Archiving liboptional.a...
Linking mame64d.exe...

real    1m56,735s
user    1m48,392s
sys 0m8,056s

Maybe cheat.cpp

find . -name cheat.[o,a]
./build/mingw-gcc/obj/x64/Debug/src/frontend/mame/cheat.o
mv ./build/mingw-gcc/obj/x64/Debug/src/frontend/mame/cheat.o ./build/mingw-gcc/obj/x64/Debug/src/frontend/mame/_cheat.o

make
GCC 6.3.0 detected
Compiling src/frontend/mame/cheat.cpp...
Archiving libfrontend.a...
Linking mame64d.exe...

real    1m30,076s
user    1m24,740s
sys 0m4,244s

I did this manually, I'm sure something can be done to make it automatic by scripting it, start with something simple like the "SOURCE=" thing, than move to the next and make the thing evolve. As you see every commit will take about 2 minutes to finish.

I don't know if you'll need to redo the archive files but is much less time to test something than doing a "tiny" version over and over again.