Avoid tampering Makefile.in in a SlackBuild? - Slackware

This is a discussion on Avoid tampering Makefile.in in a SlackBuild? - Slackware ; Hello fellow slackers; I'm writing a buildscript for the Squid proxy server that suits my needs. However, logfile directory is "$localstatedir/logs" and this can't be changed through "configure" switches. The only way I found to alter this was to insert ...

+ Reply to Thread
Results 1 to 8 of 8

Thread: Avoid tampering Makefile.in in a SlackBuild?

  1. Avoid tampering Makefile.in in a SlackBuild?

    Hello fellow slackers;

    I'm writing a buildscript for the Squid proxy server that suits my needs.
    However, logfile directory is "$localstatedir/logs" and this can't be
    changed through "configure" switches. The only way I found to alter this was
    to insert a 'sed' statement into my buildscript that substitutes "/logs" by
    "/log/squid", right after the "configure" step, but this doesn't seem like a
    good choice since the Makefile.in can change in subsequent versions of the
    source, thus rendering it useless.
    Is there another way to do this without tampering the Makefile?

    Regards

    Paulo Costa

    --
    I don't have a sig...



  2. Re: Avoid tampering Makefile.in in a SlackBuild?

    On 2007-12-17, Paulo Costa wrote:
    > Hello fellow slackers;
    >
    > I'm writing a buildscript for the Squid proxy server that suits my needs.
    > However, logfile directory is "$localstatedir/logs" and this can't be
    > changed through "configure" switches. The only way I found to alter this was
    > to insert a 'sed' statement into my buildscript that substitutes "/logs" by
    > "/log/squid", right after the "configure" step, but this doesn't seem like a
    > good choice since the Makefile.in can change in subsequent versions of the
    > source, thus rendering it useless.
    > Is there another way to do this without tampering the Makefile?



    Yes, send mail to upstream author and ask why he uses $localstatedir/logs
    instead of $localstatedir/log/ as the log directory. This assumes the
    app is "smart" enough to use that base directory as its log location -
    in other words, it would use $localstatedir/log/logfile or a subdirectory
    within $localstatedir/log/ for its logs.

    If that's not the case, and $localstatedir is not used by the app for
    any other purpose, then configure it with --localstatedir=/var/log/whatever
    (if it uses the value of $localstatedir for the actual directory for its
    own logs).

    -RW

  3. Re: Avoid tampering Makefile.in in a SlackBuild?


    "Robby Workman" escreveu na mensagem
    news:P%C9j.24249$N67.4008@bignews5.bellsouth.net.. .
    > On 2007-12-17, Paulo Costa wrote:
    >> Hello fellow slackers;
    >>
    >> I'm writing a buildscript for the Squid proxy server that suits my needs.
    >> However, logfile directory is "$localstatedir/logs" and this can't be
    >> changed through "configure" switches. The only way I found to alter this
    >> was
    >> to insert a 'sed' statement into my buildscript that substitutes "/logs"
    >> by
    >> "/log/squid", right after the "configure" step, but this doesn't seem
    >> like a
    >> good choice since the Makefile.in can change in subsequent versions of
    >> the
    >> source, thus rendering it useless.
    >> Is there another way to do this without tampering the Makefile?

    >
    >
    > Yes, send mail to upstream author and ask why he uses $localstatedir/logs
    > instead of $localstatedir/log/ as the log directory. This assumes the
    > app is "smart" enough to use that base directory as its log location -
    > in other words, it would use $localstatedir/log/logfile or a subdirectory
    > within $localstatedir/log/ for its logs.
    >
    > If that's not the case, and $localstatedir is not used by the app for
    > any other purpose, then configure it
    > with --localstatedir=/var/log/whatever
    > (if it uses the value of $localstatedir for the actual directory for its
    > own logs).
    >
    > -RW


    Thanks for the tip Robby, as well as for your participation in "Writing a
    slackbuild script" doc, which I've been using.
    I don't think this is an issue important enough that I'd bother Squid's
    authors about. I just wanted to put up a clean Slackware package where
    everything would fall in the right place right from the start and thus
    reducing the need for user intervention after the install. What I want to do
    is achievable by either:
    a) Tampering the 'Makefile.in', as in my original post;
    b) Changing 5 extra lines in Squid's configuration file, right after install
    and manually create and chmod the new log directory.
    c) Writing a doinst.sh that takes care of changing whatever needs to be
    changed, directories, permissions, config files, whatever...

    Ideally, I'd have configure switches to adjust these locations at will, and
    this post wouldn't be here... :^)

    Again, thank you for your tips and docs.

    Best regards

    Paulo Costa
    --
    I don't have a sig...



  4. Re: Avoid tampering Makefile.in in a SlackBuild?

    Paulo Costa wrote:
    > Hello fellow slackers;
    >
    > I'm writing a buildscript for the Squid proxy server that suits my needs.
    > However, logfile directory is "$localstatedir/logs" and this can't be
    > changed through "configure" switches. The only way I found to alter this was
    > to insert a 'sed' statement into my buildscript that substitutes "/logs" by
    > "/log/squid", right after the "configure" step, but this doesn't seem like a
    > good choice since the Makefile.in can change in subsequent versions of the
    > source, thus rendering it useless.
    > Is there another way to do this without tampering the Makefile?


    For clearness about what's going on I think I would prefer a patch file
    with all modifications needed. And that patch should be applied as the
    first step in the build script -even before the configure step-, rather
    than being hidden as some 'sed' statement somewhere in the script.

    Regards,

    Kees.

    --
    Kees Theunissen.


  5. Re: Avoid tampering Makefile.in in a SlackBuild?


    "Kees Theunissen" escreveu na mensagem
    news:4767b8df$0$85777$e4fe514c@news.xs4all.nl...
    >
    > For clearness about what's going on I think I would prefer a patch file
    > with all modifications needed. And that patch should be applied as the
    > first step in the build script -even before the configure step-, rather
    > than being hidden as some 'sed' statement somewhere in the script.
    >
    > Regards,
    >
    > Kees.
    >
    > --
    > Kees Theunissen.
    >


    It suffers the same limitation as the 'sed' statement - if the source file
    changes in the subsequent version then the patch will be no good. It is, as
    you noted however, a cleaner way to achieve the same result. In the
    meantime, I came across another way of doing it: by setting relevant shell
    variables during the make phase; if the variable I want to change in the
    'Makefile.in' is 'DEFAULT_LOG_PREFIX' then I'll issue a "make
    DEFAULT_LOG_PREFIX=/whatever" command. This results in a correct default
    config file but doesn't create the corresponding directory structure within
    the package, so it gives half the desired result. The directory structure
    could be corrected by the buildscript itself though.
    Thanks for the tip.

    Regards

    Paulo Costa

    --
    I don't have a sig...



  6. Re: Avoid tampering Makefile.in in a SlackBuild?

    On 2007-12-19, Paulo Costa wrote:
    >
    > I came across another way of doing it: by setting relevant shell
    > variables during the make phase; if the variable I want to change in the
    > 'Makefile.in' is 'DEFAULT_LOG_PREFIX' then I'll issue a "make
    > DEFAULT_LOG_PREFIX=/whatever" command. This results in a correct default
    > config file but doesn't create the corresponding directory structure within
    > the package, so it gives half the desired result. The directory structure
    > could be corrected by the buildscript itself though.



    That's definitely the best way to handle it.
    Sorry I didn't think to mention that :/ -- but glad you found it.


    -RW

  7. Re: Avoid tampering Makefile.in in a SlackBuild?

    In article <4768e67b$0$15344$a729d347@news.telepac.pt>,
    "Paulo Costa" wrote:
    [...]
    > In the meantime, I came across another way of doing it: by setting
    > relevant shell variables during the make phase; if the variable I
    > want to change in the 'Makefile.in' is 'DEFAULT_LOG_PREFIX' then I'll
    > issue a "make DEFAULT_LOG_PREFIX=/whatever" command.


    The method is correct, but it's important to note that these are
    Makefile variables and not shell or environment variables. The two have
    nothing to do with each other, and if you don't realize the difference
    it can get very confusing.

    For example, that's why you need to set them as an argument to the
    'make' command, and defining them the normal way won't work.

    - Martijn

  8. Re: Avoid tampering Makefile.in in a SlackBuild?


    "Martijn Dekker" escreveu na mensagem
    news:martijn-9B7C50.21222525122007@news.individual.net...
    > In article <4768e67b$0$15344$a729d347@news.telepac.pt>,
    > "Paulo Costa" wrote:
    > [...]
    >> In the meantime, I came across another way of doing it: by setting
    >> relevant shell variables during the make phase; if the variable I
    >> want to change in the 'Makefile.in' is 'DEFAULT_LOG_PREFIX' then I'll
    >> issue a "make DEFAULT_LOG_PREFIX=/whatever" command.

    >
    > The method is correct, but it's important to note that these are
    > Makefile variables and not shell or environment variables. The two have
    > nothing to do with each other, and if you don't realize the difference
    > it can get very confusing.
    >
    > For example, that's why you need to set them as an argument to the
    > 'make' command, and defining them the normal way won't work.
    >
    > - Martijn


    Thank you very much for clearing that out. In my ignorance, I thought I was
    setting shell variables.
    It's been an educational thread, thanks to all of you guys.

    Regards

    Paulo Costa

    --
    I don't have a sig...



+ Reply to Thread