Change build system from rebar2 to ...

[ates]

Hi,

What do you think about that? Proposed systems are rebar3 or erlang.mk.

The main reason for me, it's to have separate profiles for prod and test.
I want include https://github.com/ates/pcapfile library to use in tests and use real pcap files as test data.

[msantos]

I vote for rebar3 since it is now part of OTP.

I like the idea of using pcapfile for testing. One possible concern: if we have a lot of binary test data in the repo, it will affect users of the prod profile as well.

[ates]

+1 for rebar3 too. How a lot of pcaps will affect users of the prod profile? Size of repo will grow?

[ates]

Will replace rebar2 to rebar3 in separate branch

[msantos]

@ates about the test data: right, depends how much test data we plan on adding. We could end up with Kb of code and Mb's of test data. I don't know if this will really be an issue. We could create another repo for pcap data. Another option is using the files from pcapr.net but I'm not sure about the license.

About the rebar3 branch: looks good!

• I think we can get rid of the shell expansion in the makefile

# REBAR=rebar make
REBAR ?= rebar3

• think the rebar3 file got accidentally committed (contains a path to your home directory)

  I don't think we need to add rebar3 to the git repo.

• maybe add a build section to the README with "rebar3 compile"?

[ates]

The overhead of using pcap files is 24 bytes for file header and 16 bytes for record header - 40 bytes in total. Don't think it's too much :) Anyway, let's try to start using pcap files as test data, in case of some problems then move they to another repo or something else.

Fixed makefile and rebar3 binary was removed from repo. I will update README about compilation

[msantos]

On Mar 18, 2016 11:09 AM, "Artem Teslenko" notifications@github.com wrote:

The overhead of using pcap files is 24 bytes for file header and 16 bytes
for record header - 40 bytes in total. Don't think it's too much :)

Agreed :)

Anyway, let's try to start using pcap files as test data, in case of some
problems then move they to another repo or something else.

The weird thing will be that we'll have files included in the prod profile
that can't be used without pcapfile. So to be consistent we could:

• make pcapfile a dep for prod and include the pcaps in git
• have a separate git repo for the pcaps and include it in the test profile
• have pcapfile as a test build dep: read pcaps from a directory and
  convert to Erlang terms. Check the output into git.

Sorry for nitpicking. Just want to consider all the possibilities.

Fixed makefile and remove rebar3 from repo. I will update README about
compilation

Thanks!

—
You are receiving this because you commented.

Reply to this email directly or view it on GitHub

[msantos]

BTW the rebar3 branch looks good. It can be merged any time.

Having the pcap files in the tests are fine. I'll experiment with mirroring the pcapr files and running pkt on them sometime.

[ates]

Using pcap files from pcapr would be good. Not sure is it possible without login/pass.

[msantos]

Found a better source for future tests: https://github.com/the-tcpdump-group/tcpdump/tree/master/tests

These are taken from http://packetlife.net/captures/

[ates]

Nice, need to think how to reuse this in pkt

[ates]

Hmm, can't find any dumps with SCTP inside

[msantos]

wireshark seems to have some: https://wiki.wireshark.org/SampleCaptures#Stream_Control_Transmission_Protocol_.28SCTP.29

[ates]

Merged rebar3 branch to master