https://github.com/arduino/Arduino/wiki/Arduino-IDE-1.5-3rd-party-Hardware-specification provides a lot of information on how boards get installed and where. On a Mac most wind up in the /Users/[user]/Library/Arduino15/packages/ folder, which is hidden and may be hard to find. The IDE application itself contains the basics for the UNO and you’ll have to right click and select show contents to see what’s inside the package. Teensyduino also stores the hardware files inside the application package.

Increasing Serial Buffer Sizes

All sorts of problems can arise from not having a large enough buffer for serial ports, both incoming and outgoing. A call to Serial.print() will wait until it finishes, or times out, which can delay the sketch if the thing being printed requires more characters than will fit in the buffer. That delay, in turn may prevent the sketch from reading the incoming data on the receive side of the serial port before its buffer overflows. If your serial communications seem to be losing characters, you probably need a bigger buffer. Getting a bigger buffer seems to be a moving target as the code base for different processors evolves. Increasing the buffer sizes will eat up memory that is precious on an UNO, but much more available on other processors.

• For the UNO and other AVR processors, the library code is part of the application contents Arduino/Contents/Java/hardware/arduino/avr/cores/arduino/HardwareSerial.h where SERIAL_TX_BUFFER_SIZE and SERIAL_RX_BUFFER_SIZE are defined as a number of bytes unless they have been previously defined, e.g. on the command line. The standard values of 16 and 64 are tiny and you need to program accordingly, getting back to read new characters often, and not trying to send a lot of data at once unless you want to wait.
• For the Teensy 3.X family of processors, the library code is part of the application contents Arduino/Contents/Java/hardware/teensy/avr/cores/teensy3/serial1.c etc. where e.g. SERIAL1_TX_BUFFER_SIZE and SERIAL1_RX_BUFFER_SIZE are defined as a number of bytes unless they have been previously defined, e.g. on the command line. The standard values vary with the port number and are under 64. Bigger is better unless you are pushing up against memory limits.
• For the SAMD family of processors like the M0 look to e.g. /Users/[user]/Library/Arduino15/packages/arduino/hardware/samd/1.8.4/cores/arduino/RingBuffer.h for SERIAL_BUFFER_SIZE which is set to 256 unless previously defined, e.g. on the command line.  For the Adafruit SAMD products look in packages/adafruit/hardware/samd/1.5.9/cores/arduino/RingBuffer.h where it’s also 256. The comments say this is the size for the receive buffer, but I can’t find a separate spec for transmit, so I suspect it is for both. In any case, you probably don’t need to increase the value for these processors in recent versions of the libraries.

It may be easier and more effective in the long term to avoid printing too much at once, so you can do better at keeping up with the serial input.

Injecting Definitions at Compile Time

Adding a flag to the compile command line can #define a macro constant for that compilation, e.g. -DNMEA_EXTRAS=0. If you aren’t working directly at the command line, then you will need to get the Arduino (or other) IDE to add that flag when it forms the compilation command lines.  The platform.txt and boards.txt files detail to the IDE how to do all the compilations for specific boards. You can create files platform.local.txt and boards.local.txt in the same location to provide your own additional input.

# Arduino15/packages/adafruit/hardware/samd/1.5.9/platform.txt
# says this can be overridden in platform.local.txt
compiler.c.extra_flags=-DNMEA_EXTRAS=0
compiler.c.elf.extra_flags=
#compiler.c.elf.extra_flags=-v
compiler.cpp.extra_flags=-DNMEA_EXTRAS=0
compiler.S.extra_flags=
compiler.ar.extra_flags=
compiler.elf2hex.extra_flags=

could be a platform.local.txt file to add flags to command lines. Because it needs to go with the hardware definition, you can’t easily make it project specific, as you probably could with a more complex IDE like platformIO.

Unfortunately, this doesn’t work out with the Teensy platform to compile with the Teensy 3.5 (and probably other Teensies). I wound up with a boards.txt file that redefines a bunch of the elements, and will need to be updated with new Teensyduino releases (this is for v1.4.9). I will keep looking for a better solution.

# Needs to go in the hardware folder,
# not the local project folder
# e.g. Applications/Teensyduino/Contents/Java/hardware/
# teensy/avr/boards.local.txt
# Teensy doesn't support extra_flags, so you need to
# repeat the definition of the flags.defs line.
# {build.flags.defs} appears multiple places in platform.txt
# Adding to the generic compiler extra_flags fails by
# putting the -D too early on the line.
# -DNMEA_EXTRAS=0 will not include the NMEA_EXTENSIONS
teensy40.build.flags.defs=-D__IMXRT1062__ -DTEENSYDUINO=149 -DNMEA_EXTRAS
teensy36.build.flags.defs=-D__MK66FX1M0__ -DTEENSYDUINO=149 -DNMEA_EXTRAS
teensy35.build.flags.defs=-D__MK64FX512__ -DTEENSYDUINO=149 -DNMEA_EXTRAS=0
teensy31.build.flags.defs=-D__MK20DX256__ -DTEENSYDUINO=149 -DNMEA_EXTRAS
teensy30.build.flags.defs=-D__MK20DX128__ -DTEENSYDUINO=149 -DNMEA_EXTRAS
teensyLC.build.flags.defs=-D__MKL26Z64__ -DTEENSYDUINO=149 -DNMEA_EXTRAS
teensypp2.build.flags.defs=-DTEENSYDUINO=149 -DARDUINO_ARCH_AVR -DNMEA_EXTRAS
teensy2.build.flags.defs=-DTEENSYDUINO=149 -DARDUINO_ARCH_AVR -DNMEA_EXTRAS

The flags.defs elements get inserted into the right locations in the command lines.