Revision history [back]

Is it possible to compile ROS from source code using a single cmake command without using rosdep and so on tools ?

This is software, so "everything is possible", but practically, I would say: no.

For a number of reasons:

1. all packages have dependencies that need to be present before you can build them successfully. You don't need to use rosdep, but something (or someone) needs to install those dependencies
2. as packages are only loosely coupled there is no top-level CMakeLists.txt that could drive the entire build (which build would that be? There are different variants of ROS)

Is it possible to compile ROS from source code using a single cmake command without using rosdep and so on tools ?

This is software, so "everything is possible", but practically, I would say: no.

For a number of reasons:Two reasons I can come up with:

1. all packages have dependencies that need to be present before you can build them successfully. You don't need to use rosdep, but something (or someone) needs to install those dependencies
2. as packages are only loosely coupled there is no top-level CMakeLists.txt that could drive the entire build (which build would that be? There are different variants of ROS)

Is it possible to compile ROS from source code using a single cmake command without using rosdep and so on tools ?

This is software, so "everything is possible", but practically, I would say: no.

Two reasons I can come up with:

1. all packages have dependencies that need to be present before you can build them successfully. You don't need to use rosdep, but something (or someone) needs to install those dependenciesdependencies.
2. and dependencies doesn't mean just libraries like Boost, Eigen or APR, but also ROS packages that other ROS packages depend on. Something needs to make sure that those types of dependencies are also present. rosinstall_generator or rosdep do that in a typical setup.
3. a ROS workspace needs to be built in a specific order, otherwise #include statements and generated code will not work correctly. Something needs to calculate that order and then drive the build accordingly. Again: doesn't need to be Catkin/Colcon, but something (or someone) needs to do it.
4. as packages are only loosely coupled there is no top-level CMakeLists.txt that could drive the entire build (which build would that be? There are different variants of ROS)

To avoid an xy-problem, perhaps you could clarify what made you ask this?

Edit: there are approaches such as robotology/robotology-superbuild, which I believe attempt to do something like what you ask, but tbh this seems to trade one set of tools for another.

Is it possible to compile ROS from source code using a single cmake command without using rosdep and so on tools ?

This is software, so "everything is possible", but practically, I would say: no.

Two reasons I can come up with:

1. all packages have dependencies that need to be present before you can build them successfully. You don't need to use rosdep, but something (or someone) needs to install those dependencies.
2. and dependencies doesn't mean just libraries like Boost, Eigen or APR, but also ROS packages that other ROS packages depend on. Something needs to make sure that those types of dependencies are also present. rosinstall_generator or rosdep do that in a typical setup.
3. a ROS workspace needs to be built in a specific order, otherwise #include statements and generated code will not work correctly. Something needs to calculate that order and then drive the build accordingly. Again: doesn't need to be Catkin/Colcon, but something (or someone) needs to do it.
4. as packages are only loosely coupled there is no top-level CMakeLists.txt that could drive the entire build (which build would that be? There are different variants of ROS)

Edit: there are approaches such as robotology/robotology-superbuild, which I believe attempt to do something like what you ask, but tbh this seems to trade one set of tools for another.

First: to avoid an xy-problem, perhaps you could clarify what made you ask this?

As to your question:

Is it possible to compile ROS from source code using a single cmake command without using rosdep and so on tools ?

This is software, so "everything is possible", but practically, I would say: no.

Two reasons I can come up with:Some arguments:

1. all packages have dependencies that need to be present before you can build them successfully. You don't need to use rosdep, but something (or someone) needs to install those dependencies.
2. and dependencies doesn't mean just libraries like Boost, Eigen or APR, but also ROS packages that other ROS packages depend on. Something needs to make sure that those types of dependencies are also present. rosinstall_generator or rosdep do that in a typical setup.
3. a ROS workspace needs to be built in a specific order, otherwise #include statements and generated code will not work correctly. Something needs to calculate that order and then drive the build accordingly. Again: doesn't need to be Catkin/Colcon, but something (or someone) needs to do it.
4. as packages are only loosely coupled there is no top-level CMakeLists.txt that could drive the entire build (which build would that be? There are different variants of ROS)

Edit: there are approaches such as robotology/robotology-superbuild, which I believe attempt to do something like what you ask, but tbh this seems to trade one set of tools for another.

First: to avoid an xy-problem, perhaps you could clarify what made you ask this?

As to your question:

Is it possible to compile ROS from source code using a single cmake command without using rosdep and so on tools ?

Theoretically? Yes.

Practically? I would say: no.

This is software, so "everything is possible", but practically, some arguments for why I would say: no.

Some arguments:answer "no":

1. all packages have dependencies that need to be present before you can build them successfully. You don't need to use rosdep, but something (or someone) needs to install those dependencies.
2. and dependencies doesn't mean just libraries like Boost, Eigen or APR, but also ROS packages that other ROS packages depend on. Something needs to make sure that those types of dependencies are also present. rosinstall_generator or rosdep do that in a typical setup.
3. a ROS workspace needs to be built in a specific order, otherwise #include statements and generated code will not work correctly. Something needs to calculate that order and then drive the build accordingly. Again: doesn't need to be Catkin/Colcon, but something (or someone) needs to do it.
4. as packages are only loosely coupled there is no top-level CMakeLists.txt that could drive the entire build (which build would that be? There are different variants of ROS)

Edit: there are approaches such as robotology/robotology-superbuild, which I believe attempt to do something like what you ask, but tbh this seems to trade one set of tools for another.

First: re: your edit: thanks for the edit, this provides a lot more context and to be honest your original question was really unanswerable without that context.

This is a prime example of an xy-problem I believe.

As to your edit:

Unfortunately, at time of writing, we think this project is nice only for research projects , but not for use in industrial company context. And thus not ready for ROS-INDUSTRIAL for next reasons.

If you feel this technology is not for you, that is ok. No one is going to force you to use it.

As to use in industrial contexts: it could very well be true that for your use-cases using ROS does not bring value. However I would not make a blanket statement as you do in your edit. The events listed here alone indicate that there is certainly a viable way to use ROS 1 in industrial contexts. I would refer you to the RIC-EU 2018 conference recordings (playlist 1, playlist 2, playlist 3 and playlist 4) to get an impression of the many companies and research organisations using it in production environments (and yes: also in RnD).

And this is mainly a software locking issue. As machine builder and robot integrators, we should be able to provide robotician guys a platform easy to setup , use and ideally enhance.

The first step is setup. ROS should be able to be setted up easily on any platform. either binary packages are available for the operating system you are using or we can build it and integrate it. We are building our own CNC software and we must being able to know what goes inside.

This means, we will decide on which operating system to run, kernel settings , which drivers and so on ..... At the moment software is locked to some distributions and system dependencies. That's really a locking issue.

This is what I meant with providing more context: your question "can I install ROS using a CMake" seems to really have been: "are there build and deployment options for ROS other than the on the wiki documented build-a-workspace-with-Catkin workflow?".

The answer to that question would be: yes, there are.

Take a look at ros/meta-ros for instance which provides an "OpenEmbedded Layer for ROS". The various ROSCon presentations about Docker-based build and deployment pipelines may also be interesting (2018 had some nice ones). There have also been presentations about orchestration and fleet management using tools such as Kubernetes and others.

Builds and deployment for embedded systems are being discussed in the Embedded category on ROS Discourse and in the OpenEmbedded category.

While I'm not going to pretend this will solve your specific problems, it shows that others (including a rather large number of companies) have recognised that alternative deployment strategies to catkin_make need to exist and those have been created.

I would perhaps suggest to take a look at those, as right now I believe you have a somewhat skewed or one-sided impression of ROS and its development workflow.

In our software (and robotics) research development team (and any software development team), guys are used to use common used tool for developing software (CMake, autoconf, gcc compilers ....etc etc ....). Here you are providing a kind of black box (rosdep and so on tools), we can not master what is doing on the backside???

To get it out of the way: Catkin is essentially a set of functions and macros for CMake. This is a very common development approach with CMake I would say. There is no magic, it just automates some common parts of the ROS development workflow.

Do you ever use any CMake helpers? Such as CMakePackageConfigHelpers? Catkin is essentially the same thing.

Furthermore: there is no "black box": everything is open-source:

• ros/catkin
• ros/rosdep
• rosinstall_generator
• wstool

Finally: it's slightly ironic to mention autoconf and in the same sentence say something about a "black box".

We must be able to monitor / check any package licenses used too.

Of course. ROS packages should all list their licenses in their package.xml file, but that can easily miss something. So there are tools for scanning code. Both commercial and open-source. An open-source option: roscan:

Bosch Engineering GmbH aims for performing the open source scanning (OSS) of the whole ROS core software and main mobile robotics functional packages, analyses the results and prepares a referable source of their license terms and conditions.

Commercial tools also exist for this, and I'm not sure how ROS would make this any different from using other open-source software though. You could use any available tool for this.

It looks like on the back side, CMake is used, that's good to know. Cmake is provided with all battery included, this is why we don't understand the need to provide a frontend layer that complicates it, any developer don't know wtf it does, and will finally loose everybody.

For rosdep, please see whether #q215059 clears up why that exists.

For Catkin, please see whether wiki/catkin/conceptual_overview helps understand why it exists.

Regarding cmake, it is easy to download / use any particular libs that won't be available in the system and provide a complete build / install system, thus fullfills all the requirements for ROS ?. CMake can too be parameterized thanks to options.

Of course. No one is claiming that can't be done.

All "ROS build tools" (if you want to group them like that) only exist to provide additional convenience. They are not required. Every ROS package can be built using the regular mkdir build; cd build; cmake ..; make; sudo make install (provided the package author did their work correctly).

I would again suggest to take a look at the work done in ros/meta-ros and the various embedded working groups for more automated building without the "weird tools" and "complicating frontend layer[s]".

Regarding usage: We have not be able to use it in real contexts, since we had to provide a "custom ROS computer" in our applications and next to our machines (Our applications are integrated : no need to have a computer for each function, one is enough)

I can't really comment on this, as whether an additional computer makes sense in a deployment can only be determined by looking at your requirements and constraints, and I know neither.

But from offline programming viewpoint: To use ROS, command line usage is needed. This is really of another epoch, and can not be deployed in industry . Some tools need being developped to avoid it.

I won't comment on this either, as I don't feel this is a statement you can make like this.

Then, we should be able to customize interfaces and functions to the final application . eg simulation software (eg gazebo, to provide the final user, only the interface it needs and fits the application.).

There are various tools available which allow you to create more "industrial" interfaces (such as HMIs). I won't list them here now though. I would refer you to presentations at ROSCon and the ROS-Industrial Europe conference of 2018 to see a few of them.

This is why we would like to give a boost at ROS, if we could manage to bypass all these locking issue for being able to use it in real industrial context, meaning in real life.

It's great that you seem to want to help improve ROS.

I would however ask you to not make such statements as "ROS cannot be used in real industrial context, meaning real life". You seem to have a specific set of use-cases, constraints and requirements, and, compared to those, I'm more than willing to accept that ROS 1 may not meet those. I do however feel that there are plenty of examples where ROS 1 is being used in real products, in production environments and outside research labs.

My suggestion would be to reach out to people on ROS Discourse, or ask additional questions here on ROS Answers, or even contact people from the ROS-Industrial consortium. They should be able to provide you with more information.

Finally: I would recommend you to also take a look at ROS 2, as that is designed with "industrial use-cases" from the start. Whether those are your use-cases I cannot say of course.

original answer: first: to avoid an xy-problem, perhaps you could clarify what made you ask this?

As to your question:

Is it possible to compile ROS from source code using a single cmake command without using rosdep and so on tools ?

Theoretically? Yes.

Practically? I would say: no.

This is software, so "everything is possible", but some arguments for why I would answer "no":

1. all packages have dependencies that need to be present before you can build them successfully. You don't need to use rosdep, but something (or someone) needs to install those dependencies.
2. and dependencies doesn't mean just libraries like Boost, Eigen or APR, but also ROS packages that other ROS packages depend on. Something needs to make sure that those types of dependencies are also present. rosinstall_generator or rosdep do that in a typical setup.
3. a ROS workspace needs to be built in a specific order, otherwise #include statements and generated code will not work correctly. Something needs to calculate that order and then drive the build accordingly. Again: doesn't need to be Catkin/Colcon, but something (or someone) needs to do it.
4. as packages are only loosely coupled there is no top-level CMakeLists.txt that could drive the entire build (which build would that be? There are different variants of ROS)

So if you'd have all system dependencies already installed, populated a workspace with all source code for packages, determined the ROS pkg dependencies for those, figured out the build order and generated a top-level CMakeLists.txt that add_subdirectory(..)-ied all those packages in that order, it could work.

However, that is exactly what rosinstall_generator, rosdep, wstool/vcstool and Catkin or Colcon do for you.

Edit: there are approaches such as robotology/robotology-superbuild, which I believe attempt to do something like what you ask, but tbh this seems to trade one set of tools for another.

re: your edit: thanks for the edit, this provides a lot more context and to be honest your original question was really unanswerable without that context.

This is a prime example of an xy-problem I believe.

As to your edit:

Unfortunately, at time of writing, we think this project is nice only for research projects , but not for use in industrial company context. And thus not ready for ROS-INDUSTRIAL for next reasons.

If you feel this technology is not for you, that is ok. No one is going to force you to use it.

As to use in industrial contexts: it could very well be true that for your use-cases using ROS does not bring value. However I would not make a blanket statement as you do in your edit. The events listed here alone indicate that there is certainly a viable way to use ROS 1 in industrial contexts. I would refer you to the RIC-EU 2018 conference recordings (playlist 1, playlist 2, playlist 3 and playlist 4) to get an impression of the many companies and research organisations using it in production environments (and yes: also in RnD).

And this is mainly a software locking issue. As machine builder and robot integrators, we should be able to provide robotician guys a platform easy to setup , use and ideally enhance.

The first step is setup. ROS should be able to be setted up easily on any platform. either binary packages are available for the operating system you are using or we can build it and integrate it. We are building our own CNC software and we must being able to know what goes inside.

This means, we will decide on which operating system to run, kernel settings , which drivers and so on ..... At the moment software is locked to some distributions and system dependencies. That's really a locking issue.

This is what I meant with providing more context: your question "can I install ROS using a CMake" seems to really have been: "are there build and deployment options for ROS other than the on the wiki documented build-a-workspace-with-Catkin workflow?".

The answer to that question would be: yes, there are.

Take a look at ros/meta-ros for instance which provides an "OpenEmbedded Layer for ROS". The various ROSCon presentations about Docker-based build and deployment pipelines may also be interesting (2018 had some nice ones). There have also been presentations about orchestration and fleet management using tools such as Kubernetes and others.

Builds and deployment for embedded systems are being discussed in the Embedded category on ROS Discourse and in the OpenEmbedded category.

While I'm not going to pretend this will solve your specific problems, it shows that others (including a rather large number of companies) have recognised that alternative deployment strategies to catkin_make need to exist and those have been created.

I would perhaps suggest to take a look at those, as right now I believe you have a somewhat skewed or one-sided impression of ROS and its development workflow.

In our software (and robotics) research development team (and any software development team), guys are used to use common used tool for developing software (CMake, autoconf, gcc compilers ....etc etc ....). Here you are providing a kind of black box (rosdep and so on tools), we can not master what is doing on the backside???

To get it out of the way: Catkin is essentially a set of functions and macros for CMake. This is a very common development approach with CMake I would say. There is no magic, it just automates some common parts of the ROS development workflow.

Do you ever use any CMake helpers? Such as CMakePackageConfigHelpers? Catkin is essentially the same thing.

Furthermore: there is no "black box": everything is open-source:

• ros/catkin
• ros/rosdep
• rosinstall_generator
• wstool

Finally: it's slightly ironic to mention autoconf and in the same sentence say something about a "black box".

We must be able to monitor / check any package licenses used too.

Of course. ROS packages should all list their licenses in their package.xml file, but that can easily miss something. So there are tools for scanning code. Both commercial and open-source. An open-source option: roscan:

Bosch Engineering GmbH aims for performing the open source scanning (OSS) of the whole ROS core software and main mobile robotics functional packages, analyses the results and prepares a referable source of their license terms and conditions.

Commercial tools also exist for this, and I'm not sure how ROS would make this any different from using other open-source software though. You could use any available tool for this.

It looks like on the back side, CMake is used, that's good to know. Cmake is provided with all battery included, this is why we don't understand the need to provide a frontend layer that complicates it, any developer don't know wtf it does, and will finally loose everybody.

For rosdep, please see whether #q215059 clears up why that exists.exists (and related: CMakeLists.txt vs package.xml: #q217475).

For Catkin, please see whether wiki/catkin/conceptual_overview helps understand why it exists.

Regarding cmake, it is easy to download / use any particular libs that won't be available in the system and provide a complete build / install system, thus fullfills all the requirements for ROS ?. CMake can too be parameterized thanks to options.

Of course. No one is claiming that can't be done.

All "ROS build tools" (if you want to group them like that) only exist to provide additional convenience. They are not required. Every ROS package can be built using the regular mkdir build; cd build; cmake ..; make; sudo make install (provided the package author did their work correctly).

I would again suggest to take a look at the work done in ros/meta-ros and the various embedded working groups for more automated building without the "weird tools" and "complicating frontend layer[s]".

Regarding usage: We have not be able to use it in real contexts, since we had to provide a "custom ROS computer" in our applications and next to our machines (Our applications are integrated : no need to have a computer for each function, one is enough)

I can't really comment on this, as whether an additional computer makes sense in a deployment can only be determined by looking at your requirements and constraints, and I know neither.

But from offline programming viewpoint: To use ROS, command line usage is needed. This is really of another epoch, and can not be deployed in industry . Some tools need being developped to avoid it.

I won't comment on this either, as I don't feel this is a statement you can make like this.

Then, we should be able to customize interfaces and functions to the final application . eg simulation software (eg gazebo, to provide the final user, only the interface it needs and fits the application.).

There are various tools available which allow you to create more "industrial" interfaces (such as HMIs). I won't list them here now though. I would refer you to presentations at ROSCon and the ROS-Industrial Europe conference of 2018 to see a few of them.

This is why we would like to give a boost at ROS, if we could manage to bypass all these locking issue for being able to use it in real industrial context, meaning in real life.

It's great that you seem to want to help improve ROS.

I would however ask you to not make such statements as "ROS cannot be used in real industrial context, meaning real life". You seem to have a specific set of use-cases, constraints and requirements, and, compared to those, I'm more than willing to accept that ROS 1 may not meet those. I do however feel that there are plenty of examples where ROS 1 is being used in real products, in production environments and outside research labs.

My suggestion would be to reach out to people on ROS Discourse, or ask additional questions here on ROS Answers, or even contact people from the ROS-Industrial consortium. They should be able to provide you with more information.

Finally: I would recommend you to also take a look at ROS 2, as that is designed with "industrial use-cases" from the start. Whether those are your use-cases I cannot say of course.

original answer: first: to avoid an xy-problem, perhaps you could clarify what made you ask this?

As to your question:

Is it possible to compile ROS from source code using a single cmake command without using rosdep and so on tools ?

Theoretically? Yes.

Practically? I would say: no.

This is software, so "everything is possible", but some arguments for why I would answer "no":

1. all packages have dependencies that need to be present before you can build them successfully. You don't need to use rosdep, but something (or someone) needs to install those dependencies.
2. and dependencies doesn't mean just libraries like Boost, Eigen or APR, but also ROS packages that other ROS packages depend on. Something needs to make sure that those types of dependencies are also present. rosinstall_generator or rosdep do that in a typical setup.
3. a ROS workspace needs to be built in a specific order, otherwise #include statements and generated code will not work correctly. Something needs to calculate that order and then drive the build accordingly. Again: doesn't need to be Catkin/Colcon, but something (or someone) needs to do it.
4. as packages are only loosely coupled there is no top-level CMakeLists.txt that could drive the entire build (which build would that be? There are different variants of ROS)

So if you'd have all system dependencies already installed, populated a workspace with all source code for packages, determined the ROS pkg dependencies for those, figured out the build order and generated a top-level CMakeLists.txt that add_subdirectory(..)-ied all those packages in that order, it could work.

However, that is exactly what rosinstall_generator, rosdep, wstool/vcstool and Catkin or Colcon do for you.

Edit: there are approaches such as robotology/robotology-superbuild, which I believe attempt to do something like what you ask, but tbh this seems to trade one set of tools for another.

re: your edit: thanks for the edit, this provides a lot more context and to be honest your original question was really unanswerable without that context.

This is a prime example of an xy-problem I believe.

As to your edit:

Unfortunately, at time of writing, we think this project is nice only for research projects , but not for use in industrial company context. And thus not ready for ROS-INDUSTRIAL for next reasons.

If you feel this technology is not for you, that is ok. No one is going to force you to use it.

As to use in industrial contexts: it could very well be true that for your use-cases using ROS does not bring value. However I would not make a blanket statement as you do in your edit. The events listed here alone indicate that there is certainly a viable way to use ROS 1 in industrial contexts. I would refer you to the RIC-EU 2018 conference recordings (playlist 1, playlist 2, playlist 3 and playlist 4) to get an impression of the many companies and research organisations using it in production environments (and yes: also in RnD).

And this is mainly a software locking issue. As machine builder and robot integrators, we should be able to provide robotician guys a platform easy to setup , use and ideally enhance.

The first step is setup. ROS should be able to be setted up easily on any platform. either binary packages are available for the operating system you are using or we can build it and integrate it. We are building our own CNC software and we must being able to know what goes inside.

This means, we will decide on which operating system to run, kernel settings , which drivers and so on ..... At the moment software is locked to some distributions and system dependencies. That's really a locking issue.

This is what I meant with providing more context: your question "can I install ROS using a CMake" seems to really have been: "are there build and deployment options for ROS other than the on the wiki documented build-a-workspace-with-Catkin workflow?".

The answer to that question would be: yes, there are.

Take a look at ros/meta-ros for instance which provides an "OpenEmbedded Layer for ROS". The various ROSCon presentations about Docker-based build and deployment pipelines may also be interesting (2018 had some nice ones). There have also been presentations about orchestration and fleet management using tools such as Kubernetes and others.

Builds and deployment for embedded systems are being discussed in the Embedded category on ROS Discourse and in the OpenEmbedded category.

While I'm not going to pretend this will solve your specific problems, it shows that others (including a rather large number of companies) have recognised that alternative deployment strategies to catkin_make need to exist and those have been created.

I would perhaps suggest to take a look at those, as right now I believe you have a somewhat skewed or one-sided impression of ROS and its development workflow.

In our software (and robotics) research development team (and any software development team), guys are used to use common used tool for developing software (CMake, autoconf, gcc compilers ....etc etc ....). Here you are providing a kind of black box (rosdep and so on tools), we can not master what is doing on the backside???

To get it out of the way: Catkin is essentially a set of functions and macros for CMake. This is a very common development approach with CMake I would say. There is no magic, it just automates some common parts of the ROS development workflow.

Do you ever use any CMake helpers? Such as CMakePackageConfigHelpers? Catkin is essentially the same thing.

Furthermore: there is no "black box": everything is open-source:

• ros/catkin
• ros/rosdep
• rosinstall_generator
• wstool

Finally: it's slightly ironic to mention autoconf and in the same sentence say something about a "black box".

We must be able to monitor / check any package licenses used too.

Of course. ROS packages should all list their licenses in their package.xml file, but that can easily miss something. So there are tools for scanning code. Both commercial and open-source. An open-source option: roscan:

Bosch Engineering GmbH aims for performing the open source scanning (OSS) of the whole ROS core software and main mobile robotics functional packages, analyses the results and prepares a referable source of their license terms and conditions.

Commercial tools also exist for this, and I'm not sure how ROS would make this any different from using other open-source software though. You could use any available tool for this.

It looks like on the back side, CMake is used, that's good to know. Cmake is provided with all battery included, this is why we don't understand the need to provide a frontend layer that complicates it, any developer don't know wtf it does, and will finally loose everybody.

For rosdep, please see whether #q215059 clears up why that exists (and related: CMakeLists.txt vs package.xml: #q217475).

For Catkin, please see whether wiki/catkin/conceptual_overview helps understand why it exists.

Regarding cmake, it is easy to download / use any particular libs that won't be available in the system and provide a complete build / install system, thus fullfills all the requirements for ROS ?. CMake can too be parameterized thanks to options.

Of course. No one is claiming that can't be done.

All "ROS build tools" (if you want to group them like that) only exist to provide additional convenience. They are not required. Every ROS package can be built using the regular mkdir build; cd build; cmake ..; make; sudo make install (provided the package author did their work correctly).

I would again suggest to take a look at the work done in ros/meta-ros and the various embedded working groups for more automated building without the "weird tools" and "complicating frontend layer[s]".

Regarding usage: We have not be able to use it in real contexts, since we had to provide a "custom ROS computer" in our applications and next to our machines (Our applications are integrated : no need to have a computer for each function, one is enough)

I can't really comment on this, as whether an additional computer makes sense in a deployment can only be determined by looking at your requirements and constraints, and I know neither.

But from offline programming viewpoint: To use ROS, command line usage is needed. This is really of another epoch, and can not be deployed in industry . Some tools need being developped to avoid it.

I won't comment on this either, as I don't feel this is a statement you can make like this.

Then, we should be able to customize interfaces and functions to the final application . eg simulation software (eg gazebo, to provide the final user, only the interface it needs and fits the application.).

There are various tools available which allow you to create more "industrial" interfaces (such as HMIs). I won't list them here now though. I would refer you to presentations at ROSCon and the ROS-Industrial Europe conference of 2018 to see a few of them.

This is why we would like to give a boost at ROS, if we could manage to bypass all these locking issue for being able to use it in real industrial context, meaning in real life.

It's great that you seem to want to help improve ROS.

I would however ask you to not make such statements as "ROS cannot be used in real industrial context, meaning real life". You seem to have a specific set of use-cases, constraints and requirements, and, compared to those, I'm more than willing to accept that ROS 1 may not meet those. I do however feel that there are plenty of examples where ROS 1 is being used in real products, in production environments and outside research labs.

My suggestion would be to reach out to people on ROS Discourse, or ask additional questions here on ROS Answers, or even contact people from the ROS-Industrial consortium. They should be able to provide you with more information.

Finally: I would recommend you to also take a look at ROS 2, as that is designed with "industrial use-cases" from the start. Whether those are your use-cases I cannot say of course.

original answer: first: to avoid an xy-problem, perhaps you could clarify what made you ask this?

As to your question:

Is it possible to compile ROS from source code using a single cmake command without using rosdep and so on tools ?

Theoretically? Yes.

Practically? I would say: no.

This is software, so "everything is possible", but some arguments for why I would answer "no":

1. all packages have dependencies that need to be present before you can build them successfully. You don't need to use rosdep, but something (or someone) needs to install those dependencies.
2. and dependencies doesn't mean just libraries like Boost, Eigen or APR, but also ROS packages that other ROS packages depend on. Something needs to make sure that those types of dependencies are also present. rosinstall_generator or rosdep do that in a typical setup.
3. a ROS workspace needs to be built in a specific order, otherwise #include statements and generated code will not work correctly. Something needs to calculate that order and then drive the build accordingly. Again: doesn't need to be Catkin/Colcon, but something (or someone) needs to do it.
4. as packages are only loosely coupled there is no top-level CMakeLists.txt that could drive the entire build (which build would that be? There are different variants of ROS)

So if you'd have all system dependencies already installed, populated a workspace with all source code for packages, determined the ROS pkg dependencies for those, figured out the build order and generated a top-level CMakeLists.txt that add_subdirectory(..)-ied all those packages in that order, it could work.

However, that is exactly what rosinstall_generator, rosdep, wstool/vcstool and Catkin or Colcon do for you.

Edit: there are approaches such as robotology/robotology-superbuild, which I believe attempt to do something like what you ask, but tbh this seems to trade one set of tools for another.

re: your edit: thanks for the edit, this provides a lot more context and to be honest your original question was really unanswerable without that context.

This is a prime example of an xy-problem I believe.

As to your edit:

Unfortunately, at time of writing, we think this project is nice only for research projects , but not for use in industrial company context. And thus not ready for ROS-INDUSTRIAL for next reasons.

If you feel this technology is not for you, that is ok. No one is going to force you to use it.

As to use in industrial contexts: it could very well be true that for your use-cases using ROS does not bring value. However I would not make a blanket statement as you do in your edit. The events listed here alone indicate that there is certainly a viable way to use ROS 1 in industrial contexts. I would refer you to the RIC-EU 2018 conference recordings (playlist 1, playlist 2, playlist 3 and playlist 4) to get an impression of the many companies and research organisations using it in production environments (and yes: also in RnD).

And this is mainly a software locking issue. As machine builder and robot integrators, we should be able to provide robotician guys a platform easy to setup , use and ideally enhance.

The first step is setup. ROS should be able to be setted up easily on any platform. either binary packages are available for the operating system you are using or we can build it and integrate it. We are building our own CNC software and we must being able to know what goes inside.

This means, we will decide on which operating system to run, kernel settings , which drivers and so on ..... At the moment software is locked to some distributions and system dependencies. That's really a locking issue.

This is what I meant with providing more context: your question "can I install ROS using CMake" seems to really have been: "are there build and deployment options for ROS other than the on the wiki documented build-a-workspace-with-Catkin workflow?".

The answer to that question would be: yes, there are.

Take a look at ros/meta-ros (and ros-infrastructure/superflore) for instance which provides an "OpenEmbedded Layer for ROS". The various ROSCon presentations about Docker-based build and deployment pipelines may also be interesting (2018 had some nice ones). There have also been presentations about orchestration and fleet management using tools such as Kubernetes and others.

Builds and deployment for embedded systems are being discussed in the Embedded category on ROS Discourse and in the OpenEmbedded category.

While I'm not going to pretend this will solve your specific problems, it shows that others (including a rather large number of companies) have recognised that alternative deployment strategies to catkin_make need to exist and those have been created.

I would perhaps suggest to take a look at those, as right now I believe you have a somewhat skewed or one-sided impression of ROS and its development workflow.

In our software (and robotics) research development team (and any software development team), guys are used to use common used tool for developing software (CMake, autoconf, gcc compilers ....etc etc ....). Here you are providing a kind of black box (rosdep and so on tools), we can not master what is doing on the backside???

To get it out of the way: Catkin is essentially a set of functions and macros for CMake. This is a very common development approach with CMake I would say. There is no magic, it just automates some common parts of the ROS development workflow.

Do you ever use any CMake helpers? Such as CMakePackageConfigHelpers? Catkin is essentially the same thing.

Furthermore: there is no "black box": everything is open-source:

• ros/catkin
• ros/rosdep
• rosinstall_generator
• wstool

Finally: it's slightly ironic to mention autoconf and in the same sentence say something about a "black box".

We must be able to monitor / check any package licenses used too.

Of course. ROS packages should all list their licenses in their package.xml file, but that can easily miss something. So there are tools for scanning code. Both commercial and open-source. An open-source option: roscan:

Bosch Engineering GmbH aims for performing the open source scanning (OSS) of the whole ROS core software and main mobile robotics functional packages, analyses the results and prepares a referable source of their license terms and conditions.

Commercial tools also exist for this, and I'm not sure how ROS would make this any different from using other open-source software though. You could use any available tool for this.

It looks like on the back side, CMake is used, that's good to know. Cmake is provided with all battery included, this is why we don't understand the need to provide a frontend layer that complicates it, any developer don't know wtf it does, and will finally loose everybody.

For rosdep, please see whether #q215059 clears up why that exists (and related: CMakeLists.txt vs package.xml: #q217475).

For Catkin, please see whether wiki/catkin/conceptual_overview helps understand why it exists.

Regarding cmake, it is easy to download / use any particular libs that won't be available in the system and provide a complete build / install system, thus fullfills all the requirements for ROS ?. CMake can too be parameterized thanks to options.

Of course. No one is claiming that can't be done.

All "ROS build tools" (if you want to group them like that) only exist to provide additional convenience. They are not required. Every ROS package can be built using the regular mkdir build; cd build; cmake ..; make; sudo make install (provided the package author did their work correctly).

I would again suggest to take a look at the work done in ros/meta-ros and the various embedded working groups for more automated building without the "weird tools" and "complicating frontend layer[s]".

Regarding usage: We have not be able to use it in real contexts, since we had to provide a "custom ROS computer" in our applications and next to our machines (Our applications are integrated : no need to have a computer for each function, one is enough)

I can't really comment on this, as whether an additional computer makes sense in a deployment can only be determined by looking at your requirements and constraints, and I know neither.

But from offline programming viewpoint: To use ROS, command line usage is needed. This is really of another epoch, and can not be deployed in industry . Some tools need being developped to avoid it.

I won't comment on this either, as I don't feel this is a statement you can make like this.

Then, we should be able to customize interfaces and functions to the final application . eg simulation software (eg gazebo, to provide the final user, only the interface it needs and fits the application.).

There are various tools available which allow you to create more "industrial" interfaces (such as HMIs). I won't list them here now though. I would refer you to presentations at ROSCon and the ROS-Industrial Europe conference of 2018 to see a few of them.

This is why we would like to give a boost at ROS, if we could manage to bypass all these locking issue for being able to use it in real industrial context, meaning in real life.

It's great that you seem to want to help improve ROS.

I would however ask you to not make such statements as "ROS cannot be used in real industrial context, meaning real life". You seem to have a specific set of use-cases, constraints and requirements, and, compared to those, I'm more than willing to accept that ROS 1 may not meet those. I do however feel that there are plenty of examples where ROS 1 is being used in real products, in production environments and outside research labs.

My suggestion would be to reach out to people on ROS Discourse, or ask additional questions here on ROS Answers, or even contact people from the ROS-Industrial consortium. They should be able to provide you with more information.

Finally: I would recommend you to also take a look at ROS 2, as that is designed with "industrial use-cases" from the start. Whether those are your use-cases I cannot say of course.

original answer: first: to avoid an xy-problem, perhaps you could clarify what made you ask this?

As to your question:

Is it possible to compile ROS from source code using a single cmake command without using rosdep and so on tools ?

Theoretically? Yes.

Practically? I would say: no.

This is software, so "everything is possible", but some arguments for why I would answer "no":

1. all packages have dependencies that need to be present before you can build them successfully. You don't need to use rosdep, but something (or someone) needs to install those dependencies.
2. and dependencies doesn't mean just libraries like Boost, Eigen or APR, but also ROS packages that other ROS packages depend on. Something needs to make sure that those types of dependencies are also present. rosinstall_generator or rosdep do that in a typical setup.
3. a ROS workspace needs to be built in a specific order, otherwise #include statements and generated code will not work correctly. Something needs to calculate that order and then drive the build accordingly. Again: doesn't need to be Catkin/Colcon, but something (or someone) needs to do it.
4. as packages are only loosely coupled there is no top-level CMakeLists.txt that could drive the entire build (which build would that be? There are different variants of ROS)

So if you'd have all system dependencies already installed, populated a workspace with all source code for packages, determined the ROS pkg dependencies for those, figured out the build order and generated a top-level CMakeLists.txt that add_subdirectory(..)-ied all those packages in that order, it could work.

However, that is exactly what rosinstall_generator, rosdep, wstool/vcstool and Catkin or Colcon do for you.

Edit: there are approaches such as robotology/robotology-superbuild, which I believe attempt to do something like what you ask, but tbh this seems to trade one set of tools for another.