move j1939 applications to a separate repository

[hartkopp]

All,

after my failure to build the latest can-utils code with the plain Makefile here 71b2aec#commitcomment-153191516 , I thought about the dependency to libgps-dev over night.

IMO the problem is not in the Makefile but in the libgps dependency.

The can-utils are self-contained and aim to provide a bunch of tools to interact with the CAN subsystem in the Linux kernel. It can be easily compiled on every system that has a C-compiler and 'make' - even on offline systems with outdated kernel includes.
It has tools to send and receive content to the CAN_RAW/CAN_ISOTP/CAN_J1939 sockets, where things can be stored, replayed and analyzed in detail. We also have J1939 tools

PROGRAMS_J1939 := \
	j1939acd \
	j1939cat \
	j1939spy \
	j1939sr \
	testj1939

for a while now which is fine.

Recently @olerem contributed J1939 applications that do not fit the idea of "simple tools to interact with the CAN subsystem in the Linux kernel" anymore. There is a good reason why we don't have the socketcand inside the can-utils or a full blown UDS diagnosis application that randomly uses CAN_ISOTP. So why do we have a j1939-vehicle-position-srv application in can-utils??

IMHO the J1939 applications (where I also assume that only a minority of CAN users is interested in anyway) got out of control - and I would suggest to create a separate repository (e.g. can-j1939.git or can-j1939-utils.git or j1939-utils.git) to host the recently contributed J1939 applications.

[marckleinebudde]

There was a dedicated j1939 repo in the past, but we merged it here.

To ease the pain with your use-case, have a look at #588 and #589.

[hartkopp]

That does not address my general concerns on this topic.
IMO a j1939-vehicle-position-srv has no justification to be in can-utils.

[marckleinebudde]

Then let's move it out of here.

[hartkopp]

Thanks! I'm not sure which j1939 applications make sense to remain in can-utils.
I'm not generally against j1939 tools here - but it should be something on the level of cansend or isotpsend and not an application suite which continuously grows.

[marckleinebudde]

Probably move:

• isobusfs
• j1939_vehicle_position
• j1939_timedate

[hartkopp]

Yes, those are the really big chunks that are already clustered in directories.
@olerem , would this be ok for you too?
@marckleinebudde does it make sense to split up the j1939 lib stuff or link the can-utils repo from the j1939-utils repo to have the code only in one place?

[marckleinebudde]

What do you mean by link one repo to the other? If the libs in can-utils provide code that's uses by the j1939-utils, IMHO the can-utils must install these libs. The next issue to think about is the licensing of those those libs.

See #578 (comment)

[hartkopp]

I was thinking of libj1939.h and libj1939.c
AFAICS either $PROGRAMS_J1939 are referencing this code as well as isobusfs, j1939_vehicle_position, j1939_timedate

[marckleinebudde]

Yes, but what do you mean by

link the can-utils repo from the j1939-utils repo

?

[hartkopp]

I have seen, that you can have a git repository where you have e.g. a directory which points to another git repo with a specific commit. A bit like a symbolic link that needs to be pulled and updated before you can build your code.
I'm not sure how this process/concept is named.

It was:
git submodule init
git submodule update

[yegorich]

Submodules are good but I don't think, it makes the life of a package maintainer in Debian, Buildroot, etc. easier.

[marckleinebudde]

What about using shared libraries?