Change build system from rebar2 to ...

ates commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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

ates commented 8 years ago

Will replace rebar2 to rebar3 in separate branch

msantos commented 8 years ago

@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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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

msantos commented 8 years ago

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 commented 8 years ago

Nice, need to think how to reuse this in pkt

ates commented 8 years ago

Hmm, can't find any dumps with SCTP inside

msantos commented 8 years ago

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

ates commented 8 years ago

Merged rebar3 branch to master

msantos / pkt

Change build system from rebar2 to ... #30