search

NASA-Tensegrity-Robotics-Toolkit / NTRTsim

The NASA Tensegrity Robotics Toolkit Simulator, a physics based simulator to research the design and control of tensegrity robots.
Apache License 2.0
161 stars 81 forks source link

Python scripts: do we need to retain the ability to install to /usr/lib? #128

Open PerryBhandal opened 9 years ago

PerryBhandal commented 9 years ago

Does anyone install NTRT and its dependencies into /usr/lib? Or does everyone use an env based build?

As I migrate the Bash scripts to Python, I'd like to standardize our env structure so it's more consistent across packages. For example, I want to remove the ability to specify which directory gmocktest gets extracted to, which it gets built in, etc. My preferred approach would be to give each package a folder in env with three subdirectories: src, lib, include.

So, I ask:

1) Does anyone need the ability to install to /usr/lib?

2) Does anyone need the ability to specify which folder in env gmocktest is extracted to, which it's built in, etc? Or is it fine if we force all packages into an "env/package_name/src,lib,include" arrangement?

3) Can anyone think of any reason these changes shouldn't be made?

PerryBhandal commented 9 years ago

I suppose I should pitch a broader question as well: is there anything anyone dislikes about our current setup and/or build process? Are there any additional capabilities you want to see?

brtietz commented 9 years ago

One thing that we should retain is the ability to install boost from a package. This saves a lot of time and provides a nice backup - the env install failed for one of my students but packages worked. This could be a lot simpler than our current setup of course. On Jan 18, 2015 1:56 AM, "Perry Bhandal" notifications@github.com wrote:

I suppose I should pitch a broader question as well: is there anything anyone dislikes about our current setup and/or build process? Are there any additional capabilities you want to see?

— Reply to this email directly or view it on GitHub https://github.com/NASA-Tensegrity-Robotics-Toolkit/NTRTsim/issues/128#issuecomment-70398642 .

PerryBhandal commented 9 years ago

Thanks for the feedback Brian. Would the following suffice?

\ gmocktest.conf (similar cvar would be in every package's conf) **

GMOCKTEST_INSTALL_TO_ENV=false

\ general.conf **

ADDITIONAL_LIB_PATHS="/usr/lib;/home/perry/someotherlibpath"

ADDITIONAL_INCLUDE_PATHS="/usr/include;/home/perry/someotherincludepath"

brtietz commented 9 years ago

That would suit my needs. Thanks! On Jan 18, 2015 11:24 AM, "Perry Bhandal" notifications@github.com wrote:

Thanks for the feedback Brian. Would the following suffice?

\ gmocktest.conf (similar cvar would be in every package's conf) **

GMOCKTEST_INSTALL_TO_ENV=false

\ general.conf **

ADDITIONAL_LIB_PATHS="/usr/lib;/home/perry/someotherlibpath"

ADDITIONAL_INCLUDE_PATHS="/usr/include;/home/perry/someotherincludepath"

— Reply to this email directly or view it on GitHub https://github.com/NASA-Tensegrity-Robotics-Toolkit/NTRTsim/issues/128#issuecomment-70414436 .

ryan1248 commented 9 years ago

Hi Perry,

Maybe let's have a call to discuss sometime this week? I'd like to get a better understanding of the approach you're outlining and make sure we're taking into account the build dependencies (CMake, etc.). Also we may want to discuss having src, lib, and include under env, with each package placing its relevant files in these. Thoughts?

-Ryan

On Sat, Jan 17, 2015 at 10:43 PM, Perry Bhandal notifications@github.com wrote:

Does anyone install NTRT and its dependencies into /usr/lib? Or does everyone use an env based build?

As I migrate the Bash scripts to Python, I'd like to standardize our env structure so it's more consistent across packages. For example, I want to remove the ability to specify which directory gmocktest gets extracted to, which it gets built in, etc. My preferred approach would be to give each package a folder in env with three subdirectories: src, lib, include.

So, I ask:

1) Does anyone need the ability to install to /usr/lib?

2) Does anyone need the ability to specify which folder in env gmocktest is extracted to, which it's built in, etc? Or is it fine if we force all packages into an "env/package_name/src,lib,include" arrangement?

3) Can anyone think of any reason these changes shouldn't be made?

— Reply to this email directly or view it on GitHub https://github.com/NASA-Tensegrity-Robotics-Toolkit/NTRTsim/issues/128.

PerryBhandal commented 9 years ago

Hi Ryan, I'm generally free from 5 to 9PM EST every day of the week excluding Wednesday. If that works for you, let me know. If not, I'm often around during the day between lectures/labs -- it's best to catch me on Google Hangouts in that case.

The main motivation for the env// approach is to ease package management. Want to remove bullet? Delete env/bullet. Of course, I can easily modify the code to use an env/lib, env/src, env/include layout if it offers advantages.

Perry

PerryBhandal commented 9 years ago

Here are the conclusions from my discussion with Ryan this evening:

1) We'll likely use the env/package_name/src,lib,include approach.

2) .conf files are going to become .ini files. Their format will be changing slightly to be compatible with Python's ConfigParser module.

3) We'll use a /var/log style approach to logging rather than what I communicated in my e-mail to the list earlier today. So setup.py will write to base_dir/log/setup.log, build.py will write to base_dir/log/build.log.