Making RTL portable, so it can be used with different toolchains, is certainly possible -- and how/why you do this is, like everything, is an engineering tradeoff. Sometimes when you write C code it's easier to just use Linux features and not care about portability! Sometimes it's very easy (or very desirable) to keep portability for your code, which might be easy (use the standard library) or hard (use lots of #ifdef or whatever.)
But, unlike portable C code, to run designs like this on real hardware, you need to do things like describe how the physical pins on the FPGA are connected to the board peripherals (for instance, describing which pin might be connected to an LED, vs a UART). This generally requires a small amount of glue, and depending on how the project is structured, some amount of Verilog/VHDL code, as well. It's not like saying "cc -O2 foo.c" with your ported C compiler that has a POSIX standard library.
This is just the case if you're using the same base FPGA, but with different board layouts. Using different FPGAs (for example, a current-gen FPGA by vendor XYZ, vs XYZ gen N-1), or especially when porting between vendors -- the details can become vastly more complex very quickly.
But, unlike portable C code, to run designs like this on real hardware, you need to do things like describe how the physical pins on the FPGA are connected to the board peripherals (for instance, describing which pin might be connected to an LED, vs a UART). This generally requires a small amount of glue, and depending on how the project is structured, some amount of Verilog/VHDL code, as well. It's not like saying "cc -O2 foo.c" with your ported C compiler that has a POSIX standard library.
This is just the case if you're using the same base FPGA, but with different board layouts. Using different FPGAs (for example, a current-gen FPGA by vendor XYZ, vs XYZ gen N-1), or especially when porting between vendors -- the details can become vastly more complex very quickly.