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?

[hartkopp]

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

ok

[hartkopp]

What about using shared libraries?

Does that make things more complicated with installation, versioning, etc?

E.g. if you build candump for an embedded device you would like to hack then you currently only need to copy a single binary which can be executed. Without the need for installing the shared lib in a read-only filesystem.

[marckleinebudde]

Does that make things more complicated with installation, versioning, etc?

Choose your poison --- Split the code base or not.

[yegorich]

"Shared" library, as long as it doesn’t make "dynamic" calls, will be mostly shipped in both *.so and *.a variants. Hence, there should be no problems in getting only a single candump binary.

[hartkopp]

Sorry for my missing basics ... but how to I get a single candump binary after the build process generated a "dynamic" candump binary file and some *.so and *.a files?

[yegorich]

Just an example of possible packages:

• can-utils: provides/installs both candump and friends as also libcanutils.[a,so]
• j1939tools: provides j1939 binaries and libj1939utils.[a,so] and depends on can-utils

[hartkopp]

Does that make things more complicated with installation, versioning, etc?

Choose your poison --- Split the code base or not.

The j1939lib was very stable and unchanged for a long time. Therefore I would not have bad feelings to split the code base in this specific case.

[yegorich]

@hartkopp this a tutorial about the creating a static library.

But you can also pass a full path to the *.a file to link. See this answer. This way, you can override ld standard behaviour that will look for *.so first.

[hartkopp]

So it could be possible to run 'make' in a way that it creates dynamically linked binaries OR statically linked binaries?
When this is handy to use, it would be fine for me.

[marckleinebudde]

It would be cmake .. && make

[hartkopp]

But this would require cmake then

[marckleinebudde]

We can keep the Makefile as is, i.e. static linking everything. In cmake we can create static and shared libs and install them.

[hartkopp]

That's great!

[BubuOT]

When bumping this package in buildroot it came up that a full static build of can-utils no longer succeeds because when building with cmake libisobusfs is now unconditionally built as a shared library (https://github.com/linux-can/can-utils/blob/master/CMakeLists.txt#L132) if I understood the problem correctly?

There's two logs of failed builds because of that here: https://gitlab.com/jolivain/buildroot/-/jobs/9348149565 and https://gitlab.com/jolivain/buildroot/-/jobs/9348149479

I thought this might be a good place to ask if building can-utils without shared library support is going to be a supported use-case.

[yegorich]

@BubuOT does #593 fix your issue?

[marckleinebudde]

@BubuOT does #593 fix your issue?

At least it compiles the lib static, merged.

[BubuOT]

@yegorich yes, looks all good now. Thanks!