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

Conan install won't call build if a previous one with same build_id failed. #2879

Closed
NokiDev opened this issue May 9, 2018 · 7 comments
Closed
Assignees
Milestone

Comments

@NokiDev
Copy link

NokiDev commented May 9, 2018

Hi, I'm running into a weird behaviour with Conan.
When installing a project to my local cache, that had failed during a previous install (with same recipe), Conan won't call the build method and calls the package method directly, even with --build MyProject .

The workaround is to manually remove the build folder and re run conan install.

I want to know if it's a normal behavior and if there is a way to bypass it.

I appologize if there is already an issue, for the same thing I clearly didn't take enough time to check every issues, and if there is one I'll be glad to know where.

Thank you.

Configuration

  • Os : Windows 10
  • Arch : x64
  • conan version : 1.3.2
  • python version : 2.7
  • cmake version : 3.11

Conanfile

from conans import ConanFile, CMake, tools
import shutil
import os
import subprocess

class MyProjectPackage(ConanFile):
    name = "MyProject"
    license = ""
    settings = "os", "compiler", "build_type", "arch"
    generators = "cmake"
    short_paths = True
    exports_sources = "*", "test_package/*", "!conanfile.py", "!.gitignore"
    options = { "myOption" : [True, False]}
    default_options = "myOption=True"

    def build_id(self) : 
        self.info_build.options.myOption = 'Whatever'

    def build(self):
        cmake = CMake(self, generator="Visual Studio 15 2017 Win64")
        args = ['-DCMAKE_CONFIGURATION_TYPES=%s' % self.settings.build_type]
        cmake.configure(args=args)
        cmake.build(args=None, target=None)
        cmake.install(args=None, build_dir=None)

    def package(self):
        self.copy("*", dst="./", src="./EXPORT/" + str(self.settings.build_type), keep_path=True)

How to reproduce

Run :

conan export . MyProject/1.0@user/channel

Then

conan install MyProject/1.0@user/channel --build MyProject

The build failed.
Retry to install to local cache

conan install MyProject/1.0@user/channel --build MyProject

The build method is skipped, conan calls package method directly.

Here we expect the build method to be called again as with a recipe without build_id method.

@memsharded
Copy link
Member

Hi @NokiDev !

Thanks for your report. I have been playing with it, changing a few things, as-is is not reproducible, so I have used a "Hello" dependency generated with conan new, and removed the actual build() contents, as the important thing is to check that it is being called or not.

It seems it works as intended here, and the second time the build() is not called at all. If you could please try to put something that is fully reproducible, that could help (like a full github repo, or some recipe and the previous steps to be able to make it work).

Also your default_options is wrong, it should be myDep:option=value, not a dot.

Please try to provide something reproducible and we will try to help. Thanks!

@NokiDev
Copy link
Author

NokiDev commented May 10, 2018

Hi @memsharded !

I created a git repo (Here : https://github.com/NokiDev/conan_build_skipped), to highlight the issue.

Thanks for your time, and have a nice day.

@NokiDev
Copy link
Author

NokiDev commented May 13, 2018

Hi @memsharded,

After a little of investigation, the error seems to be due to this if statement in installer.py > prepare_build()

if self.build_reference != self._package_reference and \
os.path.exists(self.build_folder) and hasattr(self._conan_file, "build_id"):
    self.skip_build=True
    return

As the build folder is not removed uppon an error, (and we're using build_id () ) it leads to a skip build.

We should try to remove it, in the try / except statement in installer.py > _build_package() if the build failed or keep track of the state of the build in a file.

EDIT : Nop, forget what I was saying it's not there. I'm not familiar enough with conan source code, I suppose. I'll keep searching.

@NokiDev
Copy link
Author

NokiDev commented Oct 16, 2018

Hi @memsharded, @lasote
Seems that this issue has been forgotten...
However the bug is still present with conan 1.8.2

I' updated my repository higlighting the unwanted behaviour.
(https://github.com/NokiDev/conan_build_skipped)

As a Reminder, the problem was :
If the build step fails with a conanfile containing build_id method
Then installation / creation (conan create) of the package won't call build method, and will directly call package method.

Leading to an empty package, and no further builds.

Tell me if you need something else

@memsharded memsharded added this to the 1.9 milestone Oct 16, 2018
@memsharded memsharded self-assigned this Oct 16, 2018
@memsharded
Copy link
Member

Hi @NokiDev

Sorry for that. I have assigned the issue for next 1.9, I'll try to have a look at it for next release. Thanks for reporting and following up.

@memsharded
Copy link
Member

I am having a look at this for 1.9. Able to reproduce it, but a note about your code: It is NOT enough to return -1 in the build() method. That is not an error, and the package creation finish successfully. In order to really fail the build you need to raise an Exception (failed CMake/compile will also raise).

I have been able to reproduce, even raising exceptions, investigating possible fixes.

@NokiDev
Copy link
Author

NokiDev commented Oct 23, 2018

Okay,
Thanks for the tip, I thought that return code would be checked by Conan, my bad, I'll update my code.

Glad you be able to reproduce it !

I didn't checked if it produces this kind of issue with package_id method, but it could be great to check it as well.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants