cmake install seems to tamper with interpreter directive

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

cmake install seems to tamper with interpreter directive

Gordon Sim
It seems that the install directive for PROGRAMS in cmake somehow
evaluates and rewrites the interpreter directive in some way.

E.g. in dispatch there is:

> install(PROGRAMS
>     ${CMAKE_CURRENT_SOURCE_DIR}/tools/qdstat
>     ${CMAKE_CURRENT_SOURCE_DIR}/tools/qdmanage
>     DESTINATION bin)

The first line of both those scripts is:

> #!/usr/bin/env python

But when you install, it rewrites that to whatever that evaluates to.
This is not really what is wanted when building an install image for
installation in some other system (e.g. an rpm or a docker image), where
the setup may be different.

Does anyone know of a simple way to prevent this?

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: cmake install seems to tamper with interpreter directive

aconway.rh
On Wed, Sep 6, 2017 at 12:58 PM, Gordon Sim <[hidden email]> wrote:

> It seems that the install directive for PROGRAMS in cmake somehow
> evaluates and rewrites the interpreter directive in some way.
>
> E.g. in dispatch there is:
>
> install(PROGRAMS
>>     ${CMAKE_CURRENT_SOURCE_DIR}/tools/qdstat
>>     ${CMAKE_CURRENT_SOURCE_DIR}/tools/qdmanage
>>     DESTINATION bin)
>>
>
> The first line of both those scripts is:
>
> #!/usr/bin/env python
>>
>
> But when you install, it rewrites that to whatever that evaluates to. This
> is not really what is wanted when building an install image for
> installation in some other system (e.g. an rpm or a docker image), where
> the setup may be different.
>
> Does anyone know of a simple way to prevent this?
>
>
That boggles my mind. I tried install(FILES...) and it does the same
thing!!@#????
The cmake docs do not mention anything about such transformations,
anywhere. The string "#!" does not even occur in the docs. The install doc
says it simply copies the files, which is clearly a lie. Since there's no
mention that this "feature" even exists, I've no idea how to turn it off -
install won't allow a COPYONLY tag like configure_file, I tried. Sigh. Did
I mention I hate cmake?
Reply | Threaded
Open this post in threaded view
|

Re: cmake install seems to tamper with interpreter directive

Ken Giusti
Alan -

Hate cmake?  Maybe you'd be interested in automake instead.

/me ducks

;)

On Wed, Sep 6, 2017 at 2:44 PM, Alan Conway <[hidden email]> wrote:

> On Wed, Sep 6, 2017 at 12:58 PM, Gordon Sim <[hidden email]> wrote:
>
>> It seems that the install directive for PROGRAMS in cmake somehow
>> evaluates and rewrites the interpreter directive in some way.
>>
>> E.g. in dispatch there is:
>>
>> install(PROGRAMS
>>>     ${CMAKE_CURRENT_SOURCE_DIR}/tools/qdstat
>>>     ${CMAKE_CURRENT_SOURCE_DIR}/tools/qdmanage
>>>     DESTINATION bin)
>>>
>>
>> The first line of both those scripts is:
>>
>> #!/usr/bin/env python
>>>
>>
>> But when you install, it rewrites that to whatever that evaluates to. This
>> is not really what is wanted when building an install image for
>> installation in some other system (e.g. an rpm or a docker image), where
>> the setup may be different.
>>
>> Does anyone know of a simple way to prevent this?
>>
>>
> That boggles my mind. I tried install(FILES...) and it does the same
> thing!!@#????
> The cmake docs do not mention anything about such transformations,
> anywhere. The string "#!" does not even occur in the docs. The install doc
> says it simply copies the files, which is clearly a lie. Since there's no
> mention that this "feature" even exists, I've no idea how to turn it off -
> install won't allow a COPYONLY tag like configure_file, I tried. Sigh. Did
> I mention I hate cmake?



--
-K

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: cmake install seems to tamper with interpreter directive

Chris Richardson
autotools <shudder>

Unable to believe CMake could possibly be this rubbish (I am a devotee I'm
afraid) I've just spent the last couple of hours sifting through the
CMake's own source code to track this one down. It turns out that you have
collectively conspired to besmirch the good name of CMake and an immediate
and full retraction is required! ;)

It seems the problem here is not with CMake but actually with the
qpid-dispatch code, which has duplicate install routines for the
qdstat/qdmanager files. One is as Gordon described using
install(PROGRAMS...) and the other is via the python distutils method using
<qpid-dispatch>/python/setup.py.in; it is in fact distutils that munges the
shebang as described and not CMake at all! Removing qdstat/qdmanager from
setup.py.in fixes the problem.

CMake: 1, distutils: nil.



On 6 September 2017 at 20:00, Ken Giusti <[hidden email]> wrote:

> Alan -
>
> Hate cmake?  Maybe you'd be interested in automake instead.
>
> /me ducks
>
> ;)
>
> On Wed, Sep 6, 2017 at 2:44 PM, Alan Conway <[hidden email]> wrote:
> > On Wed, Sep 6, 2017 at 12:58 PM, Gordon Sim <[hidden email]> wrote:
> >
> >> It seems that the install directive for PROGRAMS in cmake somehow
> >> evaluates and rewrites the interpreter directive in some way.
> >>
> >> E.g. in dispatch there is:
> >>
> >> install(PROGRAMS
> >>>     ${CMAKE_CURRENT_SOURCE_DIR}/tools/qdstat
> >>>     ${CMAKE_CURRENT_SOURCE_DIR}/tools/qdmanage
> >>>     DESTINATION bin)
> >>>
> >>
> >> The first line of both those scripts is:
> >>
> >> #!/usr/bin/env python
> >>>
> >>
> >> But when you install, it rewrites that to whatever that evaluates to.
> This
> >> is not really what is wanted when building an install image for
> >> installation in some other system (e.g. an rpm or a docker image), where
> >> the setup may be different.
> >>
> >> Does anyone know of a simple way to prevent this?
> >>
> >>
> > That boggles my mind. I tried install(FILES...) and it does the same
> > thing!!@#????
> > The cmake docs do not mention anything about such transformations,
> > anywhere. The string "#!" does not even occur in the docs. The install
> doc
> > says it simply copies the files, which is clearly a lie. Since there's no
> > mention that this "feature" even exists, I've no idea how to turn it off
> -
> > install won't allow a COPYONLY tag like configure_file, I tried. Sigh.
> Did
> > I mention I hate cmake?
>
>
>
> --
> -K
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--

*Chris Richardson*, System Architect
[hidden email]


*FourC AS, Vestre Rosten 81, Trekanten, NO-7075 Tiller, Norwaywww.fourc.eu
<http://www.fourc.eu/>*

*Follow us on LinkedIn <http://bit.ly/fourcli>, Facebook
<http://bit.ly/fourcfb>, Google+ <http://bit.ly/fourcgp> and Twitter
<http://bit.ly/fourctw>!*
Reply | Threaded
Open this post in threaded view
|

Re: cmake install seems to tamper with interpreter directive

astitcher
On Wed, 2017-09-06 at 22:11 +0100, Chris Richardson wrote:
> ...
> CMake: 1, distutils: nil.

Thank you, thank you.

I was trying to understand this incoherent behaviour not quite
believing it could exist in cmake.

All-in-all cmake is like democracy (according to Churchill) - "...
democracy is the worst form of government except all those other
forms..."

Andrew

>
>
>
> On 6 September 2017 at 20:00, Ken Giusti <[hidden email]> wrote:
>
> > Alan -
> >
> > Hate cmake?  Maybe you'd be interested in automake instead.
> >
> > /me ducks
> >
> > ;)
> >
> > On Wed, Sep 6, 2017 at 2:44 PM, Alan Conway <[hidden email]>
> > wrote:
> > > On Wed, Sep 6, 2017 at 12:58 PM, Gordon Sim <[hidden email]>
> > > wrote:
> > >
> > > > It seems that the install directive for PROGRAMS in cmake
> > > > somehow
> > > > evaluates and rewrites the interpreter directive in some way.
> > > >
> > > > E.g. in dispatch there is:
> > > >
> > > > install(PROGRAMS
> > > > >     ${CMAKE_CURRENT_SOURCE_DIR}/tools/qdstat
> > > > >     ${CMAKE_CURRENT_SOURCE_DIR}/tools/qdmanage
> > > > >     DESTINATION bin)
> > > > >
> > > >
> > > > The first line of both those scripts is:
> > > >
> > > > #!/usr/bin/env python
> > > > >
> > > >
> > > > But when you install, it rewrites that to whatever that
> > > > evaluates to.
> >
> > This
> > > > is not really what is wanted when building an install image for
> > > > installation in some other system (e.g. an rpm or a docker
> > > > image), where
> > > > the setup may be different.
> > > >
> > > > Does anyone know of a simple way to prevent this?
> > > >
> > > >
> > >
> > > That boggles my mind. I tried install(FILES...) and it does the
> > > same
> > > thing!!@#????
> > > The cmake docs do not mention anything about such
> > > transformations,
> > > anywhere. The string "#!" does not even occur in the docs. The
> > > install
> >
> > doc
> > > says it simply copies the files, which is clearly a lie. Since
> > > there's no
> > > mention that this "feature" even exists, I've no idea how to turn
> > > it off
> >
> > -
> > > install won't allow a COPYONLY tag like configure_file, I tried.
> > > Sigh.
> >
> > Did
> > > I mention I hate cmake?
> >
> >
> >
> > --
> > -K
> >
> > -----------------------------------------------------------------
> > ----
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: cmake install seems to tamper with interpreter directive

Gordon Sim
In reply to this post by Chris Richardson
On 06/09/17 22:11, Chris Richardson wrote:

> autotools <shudder>
>
> Unable to believe CMake could possibly be this rubbish (I am a devotee I'm
> afraid) I've just spent the last couple of hours sifting through the
> CMake's own source code to track this one down. It turns out that you have
> collectively conspired to besmirch the good name of CMake and an immediate
> and full retraction is required! ;)
>
> It seems the problem here is not with CMake but actually with the
> qpid-dispatch code, which has duplicate install routines for the
> qdstat/qdmanager files. One is as Gordon described using
> install(PROGRAMS...) and the other is via the python distutils method using
> <qpid-dispatch>/python/setup.py.in; it is in fact distutils that munges the
> shebang as described and not CMake at all! Removing qdstat/qdmanager from
> setup.py.in fixes the problem.
>

Thanks Chris! Apologies for all the besmirching, my mistake! I retract
any and all mis-statements!

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: cmake install seems to tamper with interpreter directive

Ganesh Murthy
Should there be a Dispatch JIRA to fix this problem?

On Wed, Sep 6, 2017 at 5:43 PM, Gordon Sim <[hidden email]> wrote:

> On 06/09/17 22:11, Chris Richardson wrote:
>
>> autotools <shudder>
>>
>> Unable to believe CMake could possibly be this rubbish (I am a devotee I'm
>> afraid) I've just spent the last couple of hours sifting through the
>> CMake's own source code to track this one down. It turns out that you have
>> collectively conspired to besmirch the good name of CMake and an immediate
>> and full retraction is required! ;)
>>
>> It seems the problem here is not with CMake but actually with the
>> qpid-dispatch code, which has duplicate install routines for the
>> qdstat/qdmanager files. One is as Gordon described using
>> install(PROGRAMS...) and the other is via the python distutils method
>> using
>> <qpid-dispatch>/python/setup.py.in; it is in fact distutils that munges
>> the
>> shebang as described and not CMake at all! Removing qdstat/qdmanager from
>> setup.py.in fixes the problem.
>>
>>
> Thanks Chris! Apologies for all the besmirching, my mistake! I retract any
> and all mis-statements!
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: cmake install seems to tamper with interpreter directive

Gordon Sim
On 07/09/17 15:24, Ganesh Murthy wrote:
> Should there be a Dispatch JIRA to fix this problem?

Yes

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: cmake install seems to tamper with interpreter directive

aconway.rh
In reply to this post by Chris Richardson
Thank you Chris, I still hate cmake (not as much as autotools, and I'm
starting to despise distutils) but I have backed down to my normal "amber
alert" level of disdain. I never met a build system I didn't dislike.

On Wed, Sep 6, 2017 at 5:11 PM, Chris Richardson <[hidden email]> wrote:

> autotools <shudder>
>
> Unable to believe CMake could possibly be this rubbish (I am a devotee I'm
> afraid) I've just spent the last couple of hours sifting through the
> CMake's own source code to track this one down. It turns out that you have
> collectively conspired to besmirch the good name of CMake and an immediate
> and full retraction is required! ;)
>
> It seems the problem here is not with CMake but actually with the
> qpid-dispatch code, which has duplicate install routines for the
> qdstat/qdmanager files. One is as Gordon described using
> install(PROGRAMS...) and the other is via the python distutils method using
> <qpid-dispatch>/python/setup.py.in; it is in fact distutils that munges
> the
> shebang as described and not CMake at all! Removing qdstat/qdmanager from
> setup.py.in fixes the problem.
>
> CMake: 1, distutils: nil.
>
>
>
> On 6 September 2017 at 20:00, Ken Giusti <[hidden email]> wrote:
>
> > Alan -
> >
> > Hate cmake?  Maybe you'd be interested in automake instead.
> >
> > /me ducks
> >
> > ;)
> >
> > On Wed, Sep 6, 2017 at 2:44 PM, Alan Conway <[hidden email]> wrote:
> > > On Wed, Sep 6, 2017 at 12:58 PM, Gordon Sim <[hidden email]> wrote:
> > >
> > >> It seems that the install directive for PROGRAMS in cmake somehow
> > >> evaluates and rewrites the interpreter directive in some way.
> > >>
> > >> E.g. in dispatch there is:
> > >>
> > >> install(PROGRAMS
> > >>>     ${CMAKE_CURRENT_SOURCE_DIR}/tools/qdstat
> > >>>     ${CMAKE_CURRENT_SOURCE_DIR}/tools/qdmanage
> > >>>     DESTINATION bin)
> > >>>
> > >>
> > >> The first line of both those scripts is:
> > >>
> > >> #!/usr/bin/env python
> > >>>
> > >>
> > >> But when you install, it rewrites that to whatever that evaluates to.
> > This
> > >> is not really what is wanted when building an install image for
> > >> installation in some other system (e.g. an rpm or a docker image),
> where
> > >> the setup may be different.
> > >>
> > >> Does anyone know of a simple way to prevent this?
> > >>
> > >>
> > > That boggles my mind. I tried install(FILES...) and it does the same
> > > thing!!@#????
> > > The cmake docs do not mention anything about such transformations,
> > > anywhere. The string "#!" does not even occur in the docs. The install
> > doc
> > > says it simply copies the files, which is clearly a lie. Since there's
> no
> > > mention that this "feature" even exists, I've no idea how to turn it
> off
> > -
> > > install won't allow a COPYONLY tag like configure_file, I tried. Sigh.
> > Did
> > > I mention I hate cmake?
> >
> >
> >
> > --
> > -K
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>
>
> --
>
> *Chris Richardson*, System Architect
> [hidden email]
>
>
> *FourC AS, Vestre Rosten 81, Trekanten, NO-7075 Tiller, Norwaywww.fourc.eu
> <http://www.fourc.eu/>*
>
> *Follow us on LinkedIn <http://bit.ly/fourcli>, Facebook
> <http://bit.ly/fourcfb>, Google+ <http://bit.ly/fourcgp> and Twitter
> <http://bit.ly/fourctw>!*
>