pkt Change build system from rebar2 to ...

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.

Mar 17 '16 09:03 ates

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.

Mar 17 '16 17:03 msantos

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

Mar 18 '16 11:03 ates

Will replace rebar2 to rebar3 in separate branch

Mar 18 '16 17:03 ates

@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"?

Mar 18 '16 19:03 msantos

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

Mar 18 '16 21:03 ates

On Mar 18, 2016 11:09 AM, "Artem Teslenko" [email protected] 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

Mar 19 '16 04:03 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.

Mar 20 '16 14:03 msantos

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

Mar 21 '16 11:03 ates

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/

Mar 21 '16 11:03 msantos

Nice, need to think how to reuse this in pkt

Mar 21 '16 12:03 ates

Hmm, can't find any dumps with SCTP inside

Mar 21 '16 12:03 ates

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

Mar 21 '16 12:03 msantos

Merged rebar3 branch to master

Apr 14 '16 14:04 ates