Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider building to install space directly #54

Closed
130s opened this issue May 27, 2016 · 12 comments
Closed

Consider building to install space directly #54

130s opened this issue May 27, 2016 · 12 comments

Comments

@130s
Copy link
Member

130s commented May 27, 2016

Suggested at #48 (comment) by @rhaschke

Consider building to install space directly. I don't see a reason why to build twice, for devel and install space. This only doubles the response time of the test.

@gavanderhoorn
Copy link
Member

This makes sense, I agree with @rhaschke.

@130s
Copy link
Member Author

130s commented Jun 4, 2016

One usecase I can think of is that packages are not planned to be released so no need for install space either. In that case keeping to use devel space might be more convenient and less confusing because most of the tutorials use devel.

But I guess there may not be many users who really need to stick to devel space. So +1

@gavanderhoorn
Copy link
Member

I seem to remember the 'official policy' is to recommend using install space as much as possible, especially with catkin_tools. The devel space is kept only for a measure of backwards compatibility.

Packages failing because they have no install(..) statements is a good thing I think: missing those will also cause problems when / if people try to release those packages through the build farm, so catching that early seems like a good thing to do.

130s added a commit to 130s/industrial_ci that referenced this issue Jun 4, 2016
@rhaschke
Copy link
Contributor

rhaschke commented Jun 4, 2016

Packages failing because they have no |install(..)| statements is a
good thing I think: missing those will also cause problems when / if
people try to release those packages through the build farm, so
catching that early seems like a good thing to do.

I can only underline this argument.

130s added a commit to 130s/industrial_ci that referenced this issue Jun 5, 2016
130s added a commit to 130s/industrial_ci that referenced this issue Jun 22, 2016
130s added a commit to 130s/industrial_ci that referenced this issue Jun 23, 2016
Omit entire catkin build section when devel space is not choosed to be used.
130s added a commit to 130s/industrial_ci that referenced this issue Jun 23, 2016
Omit entire catkin build section when devel space is not choosed to be used.
130s added a commit to 130s/industrial_ci that referenced this issue Jun 23, 2016
Omit entire catkin build section when devel space is not choosed to be used.

Directory structure sorted out.
Add another pkg solely for testing only.

Conflicts:
	README.rst
	travis.sh

[.travis.yml] Allow failure for now the jade source build (see ros-industrial/industrial_core#144 (comment)).
[.travis.yml] Some more test matrix.

[Travis] Rename a file to avoid confusion.
Kinetic should better be no longer 'allow_failure'. warehouse_ros from shadow-fixed should pass.
[Travis] Remove less meaningful job (warehouse_ros prerelease). More Kinetic jobs.
130s added a commit to 130s/industrial_ci that referenced this issue Jun 23, 2016
Omit entire catkin build section when devel space is not choosed to be used.

Directory structure sorted out.
Add another pkg solely for testing only.

Conflicts:
	README.rst
	travis.sh

[.travis.yml] Allow failure for now the jade source build (see ros-industrial/industrial_core#144 (comment)).
[.travis.yml] Some more test matrix.

[Travis] Rename a file to avoid confusion.
Kinetic should better be no longer 'allow_failure'. warehouse_ros from shadow-fixed should pass.
[Travis] Remove less meaningful job (warehouse_ros prerelease). More Kinetic jobs.
@davetcoleman
Copy link
Contributor

+1 to install space by default

130s added a commit to 130s/industrial_ci that referenced this issue Aug 30, 2016
Omit entire catkin build section when devel space is not choosed to be used.

Directory structure sorted out.
Add another pkg solely for testing only.

Conflicts:
	README.rst
	travis.sh

[.travis.yml] Allow failure for now the jade source build (see ros-industrial/industrial_core#144 (comment)).
[.travis.yml] Some more test matrix.

[Travis] Rename a file to avoid confusion.
Kinetic should better be no longer 'allow_failure'. warehouse_ros from shadow-fixed should pass.
[Travis] Remove less meaningful job (warehouse_ros prerelease). More Kinetic jobs.
130s added a commit to 130s/industrial_ci that referenced this issue Aug 30, 2016
@130s
Copy link
Member Author

130s commented Sep 12, 2016

(Hopefully) fixed by #67, where I accidentally (sorry...) included the commits that try to implement the fix to this.

@130s 130s closed this as completed Sep 12, 2016
mathias-luedtke added a commit to mathias-luedtke/industrial_ci that referenced this issue Mar 6, 2017
mathias-luedtke added a commit to mathias-luedtke/industrial_ci that referenced this issue Mar 6, 2017
mathias-luedtke added a commit to mathias-luedtke/industrial_ci that referenced this issue Mar 7, 2017
mathias-luedtke added a commit to mathias-luedtke/industrial_ci that referenced this issue Mar 8, 2017
mathias-luedtke added a commit to mathias-luedtke/industrial_ci that referenced this issue Mar 8, 2017
mathias-luedtke added a commit to mathias-luedtke/industrial_ci that referenced this issue Mar 8, 2017
mathias-luedtke added a commit to mathias-luedtke/industrial_ci that referenced this issue Mar 9, 2017
mathias-luedtke added a commit to mathias-luedtke/industrial_ci that referenced this issue Mar 11, 2017
mathias-luedtke added a commit to mathias-luedtke/industrial_ci that referenced this issue Mar 20, 2017
@130s
Copy link
Member Author

130s commented Mar 22, 2017

#54 (comment)

(Hopefully) fixed by #67, where I accidentally (sorry...) included the commits that try to implement the fix to this.

I don't think my statement above is correct; #67 doesn't add anything relevant.

I think #150 fixes this.

@130s
Copy link
Member Author

130s commented Mar 26, 2017

Reopening for a discussion.

As a package with "industrial" prefix, requiring install space sounds reasonable. Users are pros, advanced grad students...

Meanwhile, when we want to escalate this package to general ROS level as we discussed (e.g. at #75 (comment)), we'll probably want to keep devel space usage. I can hardly imagine novice users and research students willing to use install space in their own software when they have no future plan to make an installable release. No?

@130s 130s reopened this Mar 26, 2017
@mathias-luedtke
Copy link
Member

we'll probably want to keep devel space usage

No. The install option just runs the provided install rules on top of the build instructions.
So if you do not specify any rules, your code is not affected at all.
If you specify rules, they get tested.

I can hardly imagine novice users and research students willing to use install space in their own software when they have no future plan to make an installable release

They don't have to, but it is recommended anyway.
As soon as projects start growing you have to take care of dependencies and package relations.
If someone does not care about these topics, CI testing is not the way to go.

@130s
Copy link
Member Author

130s commented Mar 26, 2017

Hm, I can't find where the install space is recommended, so asked.

So if you do not specify any rules, your code is not affected at all.
If you specify rules, they get tested.

When the open PR #150 gets merged, then the above won't hold any more right?

As soon as projects start growing you have to take care of dependencies and package relations.

Well managing dependency doesn't require using install space does it?

If I sound as if I changed my poistion on this subject recently, I'm sorry. I might have done that a bit. I noticed adding instructions for install in CMakeLists.txt isn't that too difficult for me but I'm not sure that's the case for all ROS users.

@mathias-luedtke
Copy link
Member

mathias-luedtke commented Mar 26, 2017

Perhaps the issue title is misleading.
We don't build directly to install space. We build to build/devel space and install the results to the install space (according to the rules).
The current behaviour is really odd:

  1. build to build/devel space
  2. run build test
  3. clean
  4. build to build/devel space and install to install space
  5. run rostest on install space

So in step 4 we are rebuilding everything from step 1, which doubles the time the build takes.

Hm, I can't find where the install space is recommended

I don't use it locally. But as soon as others depend on my packages, I have make sure that the install space is set-up properly.
So I don't recommend to use (=source) your local install space, but to add install rules for other users.

On our robots (and pool PCs) all users chain to a common (robot-specific) install space that is chained to the global /opt/ros install space.

Well managing dependency doesn't require using install space does it?

No, not directly. But the install rules make the build results explicit.
This way you can identify your build, exec and export dependencies more easily.

@130s
Copy link
Member Author

130s commented Apr 7, 2017

I posted my response #150 (review), and that PR resolves this ticket I think.

Btw, now I'm convinced that recommending install space, even for novice users, is good, after the discussing in buildsystem SIG.

@130s 130s closed this as completed Apr 7, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants