Skip to content

Choice of possible inputs to single rule #852

Open
@CT075

Description

(this was also asked on Haskell Discourse)

I’ve been trying to convert a project to use Shake, but have been stalled on the following issue.

The project configuration is made up of a list of modules, let’s say foo.m. The file foo.m is built from a .o file generated by one of two different compilers (let's say either gcc or gas).

In make, this is easy – simply have a rule relating %.m to %.o, then have multiple rules for generating %.o files. However, I am completely at a loss for how to express this with Shake.

The documentation states that, in situations where multiple compilers produce the same extension, we should adjust the filename accordingly (so, creating foo.asm.o or foo.c.o). However, I’m not sure how to write a rule choosing whichever of foo.asm.o or foo.c.o to transform into foo.m.

As far as I can tell, need requires a concrete filepath, meaning I need to know which of foo.asm.o or foo.c.o to ask for. I can’t use doesFileExist, because foo.c.o is a build artifact (and I can’t push the check to look for foo.c either, because there are some places where foo.c is generated). The actual action is the same either way, only the dependency differs. I also cannot change the extension of foo.m to foo.c.m, because the configuration only lists the name foo (it is from an external tool that I cannot change).

The only way I can think to get around this is to programatically scan the project folder ahead of time to make a bunch of explicit rules (relating foo.m to foo.c.o specifically instead of a generic rule from *.m to *.c.o if foo.c exists), but going through that kind of effort seems like it defeats the purpose of the build system.

For situations where both foo.c.o or foo.asm.o exist, I’d prefer to error out (ideally when actually constructing foo.m), but I’m happy to choose one or the other by default if needed.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions