Investigate use of consistent LMP version internally from Boost when called by liberty:dev goal #367

Activity

1. cherylking commented on Sep 10, 2019

   

   cherylking

   on Sep 10, 2019

   Member

   More actions

   Since LMP is calling the boost plugin, it seems like it could pass along the necessary info about itself so that boost could use the same version of LMP.
2. scottkurz

   changed the title [-]Investiagte use of consistent LMP version internally from Boost when called by liberty:dev goal[/-] [+]Investigate use of consistent LMP version internally from Boost when called by liberty:dev goal[/+] on Sep 10, 2019
3. scottkurz commented on Sep 12, 2019

   

   scottkurz

   on Sep 12, 2019

   ContributorAuthor

   More actions

   UPDATE: I played around a bit and at least don't see that there is any kind of fundamental problem with loading multiple versions of LMP in the liberty:dev:v1 -> boost:package -> liberty:package:v2 sequence. I was able to load mojos from the correct, distinct versions in a path like this.

   Also, noticing that ci.common hosts the ServerFeatureUtil and that each of the two LMP versions in this path will use this with static methods, I put a static init in ServerFeatureUtil and built two test LMP versions using two distinct ci.common versions (modifying the static init in ServerFeatureUtil). I saw that, correctly, each respective use of ServerFeatureUtil ran the static init for the correct version.

   So it seems the question is simply: which version of LMP do we want to use from Boost? Do we want it to be:

   • one that boost hard codes (as it does today, potentially different from the liberty:dev LMP version)
   • the one used to invoke liberty:dev?
   • another one specified by the user?

   But it's not as if there is a huge problem with how it works today

   So will leave this open to investigate.