1

I am building a snap package for my project, I have a library which I want to only compile. ie only /configure && make not : /configure && make && make install

As I had searched for the doc for it in Ubuntu snap, I found : https://snapcraft.io/docs/reference/plugins/autotools

Also searched here : https://github.com/search?o=desc&q=filename%3Asnapcraft.yaml+%22plugin%3A+autotools%22+&s=indexed&type=Code&utf8=%E2%9C%93

But I couldn't find anything to skip the make install part. Can anyone suggest me how to do that ? A dirty way might be after the make install, I will add one shell script to recursively delete the make install generated files and then proceed further to application code compilation. But I think there should be a happy path of doing this nicely. So please let me know if there is any way to skip this make install when I run snapcraft to build snap package.

ninja.stop
  • 410
  • 1
  • 10
  • 24
  • I'm not much familiar with snap, but I've done a lot of packaging in other formats, and what you suggests sounds awfully fishy. What do you expect to accomplish by skipping `make install`? What do you think would be included in the package in that case? Because my first guess would be "nothing". – John Bollinger Jun 20 '17 at 13:12
  • I just want to compile it, I will link that compiled lib with my code and then I will install that. i do not want to install the library binaries as well. That is what I want to achieve. make install of lib will install the library binaries to a specific folder which is also packaged to that snap. I do not want to do that. Hopefully I am able to explain the 'fishy' part – ninja.stop Jun 21 '17 at 05:45
  • 1
    You seem to be working against the system. It would be natural to build the library(-ies) as *shared* libraries, even though they are dedicated to the application you are packaging, and to link them dynamically. In that case, you would indeed need to package the library binaries. That model is pretty common in general, and it seems to be the one targeted by snap in particular. – John Bollinger Jun 21 '17 at 13:07
  • If you're going to link the application(s) statically, then you don't need snap. The primary characteristic distinguishing it from most other packaging formats is exactly that it packages the dependencies (i.e. shared libraries) together with the application that requires them. – John Bollinger Jun 21 '17 at 13:09
  • @JohnBollinger Against the system? Not really. I don't want that library to be a shared one. I Just want my application to be compiled and shipped as a snap application. I am able to do that by dirty hacks. But I want to do it in better way. I just wanted to know how it could be done through the snap way. – ninja.stop Jun 23 '17 at 06:35
  • You seem not to be getting the point. Trying to avoid the library, provided by a separate project, being used as a shared one *is* working against the system. That is why you're having trouble finding an easy way to do it. There isn't any snap way to do it as far as I can tell. Separately from snap, however, you could integrate the source of the library directly into your own project, and build and link it however you like via that project's own build system instead of the library's. But I really think you should reconsider. – John Bollinger Jun 23 '17 at 13:54
  • @JohnBollinger The lib was not shared by any separate project, neither it was intended as well. make install is an optional step. You may or may not use it. However I solved my problem. Thanks for your suggestions. I will reconsider in case of shared libs – ninja.stop Jun 24 '17 at 14:14

1 Answers1

1

I got my answer by trial and error method. The solution is :

artifacts: [.]

at snapcraft.yaml file. As per the doc, it makes default make install skip. I was keeping it as nil but was not working. But this one worked pretty well, also the permision denied error is gone (snapcraft wanted to install in system, hence sudo was the solution there).

ninja.stop
  • 410
  • 1
  • 10
  • 24