[llvm-dev] cmake: program name prefix?

167 views
Skip to first unread message

Johnson, Nicholas Paul via llvm-dev

unread,
Jan 19, 2016, 11:48:25 AM1/19/16
to llvm...@lists.llvm.org
Using cmake, is it possible to specify a prefix string to prepended to all installed executable files? For example, the executable file prefix "x86-linux-elf-" would result in executables named "x86-linux-elf-opt", "x86-linux-elf-llc", etc.

Thanks,
Nick Johnson
D. E. Shaw Research

_______________________________________________
LLVM Developers mailing list
llvm...@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

Johnson, Nicholas Paul via llvm-dev

unread,
Jan 26, 2016, 11:42:10 AM1/26/16
to llvm...@lists.llvm.org, cbie...@apple.com
Thanks, Chris, for your reply.

> I'm a little curious why you want it.

We want to use the clang+llvm toolchain for two different targets: x86-64 and our in-house architectures. We find it useful to compile these targets into separate binaries for a few reasons:

(1) Our targets use different libc implementations (glibc vs newlib) and must be configured with different sysroots. AFAICT, DEFAULT_SYSROOT is not a target-specific configuration variable.

(2) Whereas our x86 target is vanilla clang/llvm, our in-house target is more experimental. It's handy to segregate the experimental features, especially for some of our users who just want to use a stable compiler.

and,

(3) Inertia: this is how we have done it in the past with previous, gcc-based iterations of the toolchain.

Thanks,
Nick


>-----Original Message-----
>From: cbie...@apple.com [mailto:cbie...@apple.com]
>Sent: Monday, January 25, 2016 12:26 PM
>To: Johnson, Nicholas Paul
>Subject: Re: [llvm-dev] cmake: program name prefix?
>
>Our current CMake doesn't support that. It could probably be added, but I'm a
>little curious why you want it. I don't think opt and llc are setup to read their
>targets from their names, and in general those tools aren't really designed to
>be shipped as part of a toolchain.
>
>_Chris
>
>Sent from my iPad
>
>> On Jan 19, 2016, at 8:48 AM, Johnson, Nicholas Paul via llvm-dev <llvm-

Neil Henning via llvm-dev

unread,
Jan 26, 2016, 12:04:54 PM1/26/16
to llvm...@lists.llvm.org
At a guess if you really wanna do this, you could have a parent CMakeLists.txt which would include the LLVM CMakeLists.txt, and in the parent one you'd want to override add_executable (like in this example https://cmake.org/pipermail/cmake/2011-March/043320.html) to change the name of the executable target. Your best to do set_target_properties with OUTPUT_NAME to do that.

No idea if this works, but I've done similar horrific things in CMake before and they tend to work.

Best of luck,

-Neil.

Krzysztof Parzyszek via llvm-dev

unread,
Jan 26, 2016, 12:10:35 PM1/26/16
to llvm...@lists.llvm.org
On 1/26/2016 10:41 AM, Johnson, Nicholas Paul via llvm-dev wrote:
>
> (3) Inertia: this is how we have done it in the past with previous, gcc-based iterations of the toolchain.
>

We do the exact same thing with our Hexagon compiler. The executables
that we ship are prefixed with hexagon-. We do some postprocessing to
make sure "make install" does it for us, and having a direct support for
it in the cmake files would be really nice.

-Krzysztof


--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation

Johnson, Nicholas Paul via llvm-dev

unread,
Jan 27, 2016, 10:16:24 AM1/27/16
to llvm...@lists.llvm.org, cbie...@apple.com
Thanks all for replies.

Krysztof said:
>We do the exact same thing with our Hexagon compiler. The executables
>that we ship are prefixed with hexagon-.

Chris Bieneman said:
>You also need changes to llc, opt (and any other tools you
>want) so that they read the target triple from their names.
>

Chris' reply assumes that the prefix string must be a target triple and thus should be parsed by tools. It might be easier to do a halfway step: provide a PROGRAM_PREFIX option, but not require that the prefix string correspond to a target triple descriptor string. This sounds like it would also satisfy Krzysztof's use case (as "hexagon-" is not a target triple specifier anyway) and it would satisfy mine too.

I am curious, would the project be interested in such a half-way patch?

Nick

Krzysztof Parzyszek via llvm-dev

unread,
Jan 29, 2016, 11:57:32 AM1/29/16
to llvm...@lists.llvm.org, cbie...@apple.com
On 1/27/2016 9:16 AM, Johnson, Nicholas Paul via llvm-dev wrote:
>
> I am curious, would the project be interested in such a half-way patch?

Given that there are two use cases already, I'd suggest that there is
indeed an interest. Those who don't need this will probably not be
actively interested, so as long as nobody objects, I'd say, let's do it.

To recap: the proposal is to add a cmake argument PROGRAM_PREFIX=xyz,
whose only function would be to prepend "xyz" to the names of all
binaries installed through the "install" target. The default would be
an empty string (or an unset value), so those who don't specify it won't
see any change.

Are there any objections to this?

-Krzysztof


--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation

Robinson, Paul via llvm-dev

unread,
Jan 29, 2016, 1:06:20 PM1/29/16
to Krzysztof Parzyszek, llvm...@lists.llvm.org, cbie...@apple.com
> On 1/27/2016 9:16 AM, Johnson, Nicholas Paul via llvm-dev wrote:
> >
> > I am curious, would the project be interested in such a half-way patch?
>
> Given that there are two use cases already, I'd suggest that there is
> indeed an interest. Those who don't need this will probably not be
> actively interested, so as long as nobody objects, I'd say, let's do it.
>
> To recap: the proposal is to add a cmake argument PROGRAM_PREFIX=xyz,
> whose only function would be to prepend "xyz" to the names of all
> binaries installed through the "install" target. The default would be
> an empty string (or an unset value), so those who don't specify it won't
> see any change.
>
> Are there any objections to this?

Not from here. FWIW we also rename the build products, currently in a
separate packaging step that we do anyway. So, we're unlikely to take
advantage of the feature ourselves, but it's certainly a reasonable thing
to want.
--paulr
Reply all
Reply to author
Forward
0 new messages