[erlang-questions] rebar question

[Tim Watson]

You can do this by including a rebar.config.script in the project, which is handled with file:script/1 to produce the config. This can read the regular rebar.config (either using file:consult/1 or rebar_config) and modify whatever it likes. An alternative is to write a plugin which hooks into the post_compile:

-module(example).

post_compile(Conf, _) ->
    %% move the binar wherever you want
    ok.

On 29 Sep 2012, at 15:03, Serge Aleynikov <serge@REDACTED> wrote:

> In order to compile a port program using rebar, I need to place the
> resulting port program in the architecture-specific folder:
>    priv/$ARCH/exec-port
> 
> where $ARCH is the result of the call:
>    erlang:system_info(system_architecture)
> 
> I was thinking of setting ARCH in the pre-compile hook.  However, it
> doesn't seem that the "port_specs" config clause allows expansion of
> environment variables, so if the "ARCH" variable has a value, the
> following won't work:
> 
> {port_specs, [{"priv/$ARCH/exec-port", ["c_src/*.cpp"]}]}.
> 
> Is there a work-around I could use to accomplish this?
> 
> On 9/29/2012 5:23 AM, Tim Watson wrote:
>> I'm a heavy rebar user and have compiled ports with it before, so give me a shout if you need any assistance. I can also do testing on several unix platforms. 
>> 
>> On 28 Sep 2012, at 22:41, Serge Aleynikov <serge@REDACTED> wrote:
>> 
>>> Unfortunately I don't have OSx to test this.  I can't reproduce your
>>> problem on Linux.  Perhaps you could check the libtool version this way:
>>> 
>>> $ grep "^macro_version" /usr/bin/libtool
>>> macro_version=2.4
>>> 
>>> and if yours is different, try to upgrade it.
>>> 
>>> In order to simplify the build process I'll try to convert erlexec to
>>> use rebar some time next week, which will eliminate autotools-based
>>> toolchain.  Need to figure out with rebar how to test and optionally
>>> enable conditional defines based on presence of special C headers such
>>> as "sys/capability.h" when compiling a port program.
>>> 
>>> On 9/28/2012 5:16 PM, Tim Watson wrote:> Well I do, but clearly not the
>>> same version as you?
>>>> 
>>>> t4@REDACTED:erlexec $ which libtool
>>>> /usr/bin/libtool
>>>> t4@REDACTED:erlexec $ ls -la /usr/bin/ | grep libtool
>>>> -r-xr-xr-x     1 root   wheel    149216 22 May 15:30 libtool
>>>> lrwxr-xr-x     1 root   wheel         7 22 May 15:30 ranlib -> libtool
>>>> t4@REDACTED:erlexec $ libtool --version
>>>> libtool: unknown option character `-' in: --version
>>>> Usage: libtool -static [-] file [...] [-filelist listfile[,dirname]]
>>> [-arch_only arch] [-sacLT]
>>>> Usage: libtool -dynamic [-] file [...] [-filelist listfile[,dirname]]
>>> [-arch_only arch] [-o output] [-install_name name]
>>> [-compatibility_version #] [-current_version #] [-seg1addr 0x#]
>>> [-segs_read_only_addr 0x#] [-segs_read_write_addr 0x#] [-seg_addr_table
>>> <filename>] [-seg_addr_table_filename <file_system_path>] [-all_load]
>>> [-noall_load]
>>>> t4@REDACTED:erlexec $
>>>> 
>>>> Honestly the osx build tool chain drives me nuts sometimes. :/
>>>> 
>>>> On 28 Sep 2012, at 17:24, Serge Aleynikov wrote:
>>>> 
>>>>> Is it possible that you don't have libtool installed (missing
>>>>> AC_PROG_LIBTOOL)?
>>>>> 
>>>>> I have the following on linux and everything builds fine:
>>>>> $ autoconf -V
>>>>> autoconf (GNU Autoconf) 2.68
>>>>> $ libtool --version
>>>>> libtool (GNU libtool) 2.4
>>>>> $ ./build
>>>>> $ make
>>>>> $ make install
>>>>> $ tree install
>>>>> install
>>>>> └── exec-1.0
>>>>>  ├── ebin
>>>>>  │   ├── exec.app
>>>>>  │   ├── exec_app.beam
>>>>>  │   └── exec.beam
>>>>>  ├── include
>>>>>  │   └── exec.hrl
>>>>>  ├── priv
>>>>>  │   └── x86_64-unknown-linux-gnu
>>>>>  │       └── bin
>>>>>  │           └── exec-port
>>>>>  └── src
>>>>>      ├── exec_app.erl
>>>>>      └── exec.erl
>>>>> 
>>>>> 
>>>>> On 9/28/2012 7:45 AM, Tim Watson wrote:> The project doesn't appear to
>>>>> build cleanly on mac os lion:
>>>>>> 
>>>>>> t4@REDACTED:erlexec $ ./configure
>>>>>> configure: error: cannot find install-sh, install.sh, or shtool in
>>>>> config "."/config
>>>>>> t4@REDACTED:erlexec $ ./build
>>>>>> Install dir: /usr/local/src/erlang/erlexec/install
>>>>>> aclocal
>>>>>> autoconf -i
>>>>>> configure.ac:19: error: possibly undefined macro: AC_PROG_LIBTOOL
>>>>>>   If this token and others are legitimate, please use
>>> m4_pattern_allow.
>>>>>>   See the Autoconf documentation.
>>>>>> make: *** [configure] Error 1
>>>>>> t4@REDACTED:erlexec $
>>>>>> t4@REDACTED:erlexec $ autoconf -V
>>>>>> autoconf (GNU Autoconf) 2.69
>>>>>> Copyright (C) 2012 Free Software Foundation, Inc.
>>>>>> License GPLv3+/Autoconf: GNU GPL version 3 or later
>>>>>> <http://gnu.org/licenses/gpl.html>,
>>>>> <http://gnu.org/licenses/exceptions.html>
>>>>>> This is free software: you are free to change and redistribute it.
>>>>>> There is NO WARRANTY, to the extent permitted by law.
>>>>>> 
>>>>>> Written by David J. MacKenzie and Akim Demaille.
>>>>>> t4@REDACTED:erlexec $
>>>>>> 
>>>>>> 
>>>>>> Is there a specific version of autotools required to build and compile
>>>>> erlexec?
>>>>>> 
>>>>>> On 27 Sep 2012, at 20:11, Tim Watson wrote:
>>>>>> 
>>>>>>> On 27 Sep 2012, at 19:18, freza@REDACTED wrote:
>>>>>>>> Haven't been following this thread closely, but it seems erlexec
>>> wasn't
>>>>>>>> mentioned yet:
>>>>>>>> 
>>>>>>>>   http://code.google.com/p/erlexec/
>>>>>>> 
>>>>>>> Doesn't appear very well maintained. I might pick it apart and
>>>>> rewrite it when native processes get released - it is a cool idea.
>>>>> Anyway, for the time being it's not a great help as I'm writing a
>>>>> framework to help set up and tear down clusters for distributed testing
>>>>> (based largely on common test) so I want to minimise the number of
>>>>> dependencies as much as possible. Besides, I'm more interested in
>>>>> working on the remote/ssh runner+monitor next, rather than spending
>>>>> another age fiddling around with the script runner.
>>>>>>> 
>>>>>>> But yes, erlexec does look interesting and has been on my radar since
>>>>> it popped up on this list a few months back, discussing the desire to do
>>>>> proper signal handling (such as sending SIGTERM, SIGHUP, etc to the
>>>>> external program) without resorting to os:cmd("kill -" ++ Code ++ " " ++
>>>>> OsPid). Again, this is something that linked-in drivers *can* deal with
>>>>> to a limited extent, and therefore I suspect that native processes will
>>>>> make for a very nice foundation on which to build an alternative to
>>>>> open_port/2.
>>>>>>> 
>>>>>>> Also, IIRC there was a cool command line testing framework open
>>>>> sourced in the last year which was announced on this list. I can't
>>>>> remember what it was called, but it has a port driver that handles the
>>>>> the external comms and so on - looked very nice, although that's not
>>>>> what I'm trying to do/be as my focus is on getting things in a
>>>>> consistent state and monitoring to make sure they stay that way through
>>>>> the test run, then tearing down nicely before the next phase kicks off.
>>>>>>> 
>>>>>>> Cheers,
>>>>>>> Tim
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> _______________________________________________
>>>>>> erlang-questions mailing list
>>>>>> erlang-questions@REDACTED
>>>>>> http://erlang.org/mailman/listinfo/erlang-questions
>>>>>> 
>>>>