You are here: Home » Topic » How to build?

How to build?

This topic contains 5 replies, has 1 voice, and was last updated by  rpedde 11 years, 1 month ago.

Viewing 6 posts - 1 through 6 (of 6 total)
  • Author
    Posts
  • #409

    peller

    Sorry if this is obvious, but can anyone help me figure out how to do a build on Linux? I looked at the readme which starts at ./configure. I tried doing an autoconf, but I must be missing some dependencies and/or switches?

    autoconf says:

    configure.in:6: error: possibly undefined macro: AM_CONFIG_HEADER
    If this token and others are legitimate, please use m4_pattern_allow.
    See the Autoconf documentation.
    configure.in:7: error: possibly undefined macro: AM_INIT_AUTOMAKE
    configure.in:13: error: possibly undefined macro: AC_PROG_LIBTOOL
    configure.in:21: error: possibly undefined macro: AM_CONDITIONAL

    then ./configure says:

    configure: error: cannot find sources (config.h.in) in . or ..

    (Sorry, I’m pretty ignorant when it comes to autoconf)

    I’d like to try fixing #78 and #79, which don’t look too hard.

    -Adam

    #5408

    rpedde
    Participant

    @peller wrote:

    Sorry if this is obvious, but can anyone help me figure out how to do a build on Linux? I looked at the readme which starts at ./configure. I tried doing an autoconf, but I must be missing some dependencies and/or switches?

    autoconf says:

    configure.in:6: error: possibly undefined macro: AM_CONFIG_HEADER
    If this token and others are legitimate, please use m4_pattern_allow.
    See the Autoconf documentation.
    configure.in:7: error: possibly undefined macro: AM_INIT_AUTOMAKE
    configure.in:13: error: possibly undefined macro: AC_PROG_LIBTOOL
    configure.in:21: error: possibly undefined macro: AM_CONDITIONAL

    then ./configure says:

    configure: error: cannot find sources (config.h.in) in . or ..

    (Sorry, I’m pretty ignorant when it comes to autoconf)

    I’d like to try fixing #78 and #79, which don’t look too hard.

    -Adam

    Copy reconf.sh.templ to reconf.sh, and run that. You’ll need libtool installed, as well as automake. That should go, so long as you have reasonably recent auto tools.

    If you want the fix for #78 and #79 merged, make it an environment variable, and replace popen with exec. Something like http://www.iu.hio.no/~mark/unix/unix.html#SEC178 might be helpful. Also, kill the process if it doesn’t die by itself when stdin closes. That’s what #78 and #79 are waiting on, so you can speed the process by doing it that way to being with.

    — Ron

    #5409

    peller

    You read my mind about the exec()… though I’m extremely rusty at unix/C++ so this trivial exercise may take me a while.

    #5410

    rpedde
    Participant

    @peller wrote:

    You read my mind about the exec()… though I’m extremely rusty at unix/C++ so this trivial exercise may take me a while.

    yeah, the exec way is definitely the Right Thing To Do, and fixes the zombie process thing on decoders that don’t exit on stdin closing (alac decoder, I’m talking about you).

    Do look at that link, though, it’s got a popen-compatable interface for exec. Should be easy to drop in almost as-is.

    — Ron

    #5411

    peller

    So where does one find id3tag.h? (Again, silly n00b question)

    Taking this a bit further, can the mt-daapd.sh script be modified to do script execs to spawn off the corresponding transcoder? This would mean one less process per transcode, and every little bit helps on the slug. (I’ll try to do this as well, provided I get around to making the build work)

    I like the idea of putting the parameters in environment variables instead of $1, $2… I’m thinking all the HTTP headers are useful to the transcoding script, including accepted deflaters (gzip) etc.

    #5412

    rpedde
    Participant

    @peller wrote:

    So where does one find id3tag.h? (Again, silly n00b question)

    It’s part of libid3tag.

    Taking this a bit further, can the mt-daapd.sh script be modified to do script execs to spawn off the corresponding transcoder? This would mean one less process per transcode, and every little bit helps on the slug. (I’ll try to do this as well, provided I get around to making the build work)

    Yeah, you could, but it would make it a lot less flexible at the expense of one process (and processes are cheap on linux — plus, you already probably have a couple busyboxes running, so you’re sharing whatever pages are shareable anyway). I’d consider it to be not worth it.

    I like the idea of putting the parameters in environment variables instead of $1, $2… I’m thinking all the HTTP headers are useful to the transcoding script, including accepted deflaters (gzip) etc.

    Yup. Source IP, song ID, any number of other pieces of info.

Viewing 6 posts - 1 through 6 (of 6 total)

You must be logged in to reply to this topic.