[3.1] fix libff in 3.1 tester cmakes

[oschwaldp-oci]

Fix issues seen with libff when trying to use mandel with mandel.cdt.

Update CMakeLists.txt to create a parallel mandel-config.cmake for use until mandel goes through renaming.

Update path to libff in fc libraries when using build from src.

Add install directions for current mandel use with mandel.cdt (or others).

Resolves: #426
Resolves: #420

Supersedes: #421

Relates to mandel.cdt issue/PR:
eosnetworkfoundation/mandel.cdt#25
eosnetworkfoundation/mandel.cdt#26

[spoonincode]

make -j $(nproc) dev-install will combine all 3 of these lines

[oschwaldp-oci]

Updated: b955a8b

[spoonincode]

We don't want to encourage users to install dev components in to /usr/local because it causes conflicts. Will need to use something else (idk what we've been indecisive; maybe $HOME/mandeldev 🤷 ).

[oschwaldp-oci]

Update: 2d05d35

[spoonincode]

EosioTesterBuild.cmake is used when users do not want to install the dev files to use them for native contract user testing. EosioTester.cmake is used when the dev files are installed.

Does EosioTester.cmake need to be changed too? This PR is only changing EosioTesterBuild.cmake.

(this is part of the reason I'm not really sure how to feel about encouraging users to install the dev files at all -- it's not strictly needed)

[oschwaldp-oci]

EosioTesterBuild.cmake is used when users do not want to install the dev files to use them for native contract user testing. EosioTester.cmake is used when the dev files are installed.

Understood.

Does EosioTester.cmake need to be changed too? This PR is only changing EosioTesterBuild.cmake.

EosioTesterBuild.cmake needed to be updated due to changes made to fc and where libff was moved.
EosioTester.cmake still makes use of @CMAKE_INSTALL_PREFIX@ to find libff. When doing the dev install instructions, libff is still installed in @CMAKE_INSTALL_PREFIX@/lib -- thus no changes were needed there.

(this is part of the reason I'm not really sure how to feel about encouraging users to install the dev files at all -- it's not strictly needed)

Understood. However, the option to install still currently exists with little, if any, documentation. Was trying to smooth the path to making use of it for a user. We may still want to make changes to the install methodology or remove it if no longer wanted/supported/needed.

[spoonincode]

Okay, we definitely do not want to encourage /usr/local though. It's a disaster. I'd even say there needs to be something in the README warning users to place it elsewhere since /usr/local is the default

[spoonincode]

I even toyed with the idea of disabling the dev component when the install prefix is /usr or /usr/local, but didn't go through with it. Maybe that's another option we could entertain.

[oschwaldp-oci]

Okay, we definitely do not want to encourage /usr/local though. It's a disaster. I'd even say there needs to be something in the README warning users to place it elsewhere since /usr/local is the default

That sounds like a good idea. Is there a specific location you'd like to use? Do you like your previous suggestion of $HOME/mandeldev enough to move forward with that? I can make something generic and then connect the dots between mandel and mandel.cdt README instructions.

[larryk85]

Okay, we definitely do not want to encourage /usr/local though. It's a disaster. I'd even say there needs to be something in the README warning users to place it elsewhere since /usr/local is the default

That sounds like a good idea. Is there a specific location you'd like to use? Do you like your previous suggestion of $HOME/mandeldev enough to move forward with that? I can make something generic and then connect the dots between mandel and mandel.cdt README instructions.

I would recommend making this one generic so $HOME/mandeldev is fine with me.

For the most part in the future devs should have the dev package available so this instruction would be for outliers anyway.

[spoonincode]

Yeah that's the thing, you don't need to install it to use it with cdt, so do we really want to encourage installing it in the first place? (With a marque entry in the README no less)

The existing mandel-contracts documentation already is written as not performing an install and just using the build dir. Do we really feel an alternative approach to our own suggestion in that repo needs to be prominent and encouraged here?

[oschwaldp-oci]

Yeah that's the thing, you don't need to install it to use it with cdt, so do we really want to encourage installing it in the first place? (With a marque entry in the README no less)

The existing mandel-contracts documentation already is written as not performing an install and just using the build dir. Do we really feel an alternative approach to our own suggestion in that repo needs to be prominent and encouraged here?

Fair point. How would you prefer to proceed? Simply delete the section on installation or is there a less marquee location to document this as a reference for someone specifically looking?

[larryk85]

Yeah that's the thing, you don't need to install it to use it with cdt, so do we really want to encourage installing it in the first place? (With a marque entry in the README no less)
The existing mandel-contracts documentation already is written as not performing an install and just using the build dir. Do we really feel an alternative approach to our own suggestion in that repo needs to be prominent and encouraged here?

Fair point. How would you prefer to proceed? Simply delete the section on installation or is there a less marquee location to document this as a reference for someone specifically looking?

I would recommend just leaving the install step out of the README for now. We really should be moving to using the dev packages for this use case anyway. So, the documentation for mandel-contracts can stay as it is now, but move to listing the dev package and installation of that as the way to build it's contracts.

[spoonincode]

Yeah my hunch is to shy away from even mentioning it in the README.

However, it is a behavior change compared to pre 3.1, so I could see something in the release notes long the lines of

For users utilizing native contract unit testing, make install no longer installs the required header and libraries. It's recommended to utilize the headers and libraries directly from mandel's build directory, or to use the mandel-dev package. Installation of these headers and libraries can still be performed with a make dev-install if absolutely needed.

[oschwaldp-oci]

Yeah my hunch is to shy away from even mentioning it in the README.

However, it is a behavior change compared to pre 3.1, so I could see something in the release notes long the lines of

For users utilizing native contract unit testing, make install no longer installs the required header and libraries. It's recommended to utilize the headers and libraries directly from mandel's build directory, or to use the mandel-dev package. Installation of these headers and libraries can still be performed with a make dev-install if absolutely needed.

Sounds like a plan. I will remove the install directions from the README.