Hi all,
I am currently working on https://gerrit.osmocom.org/#/c/2075/ The problem is that the conv.h should be shared between several source code files, and it works fine for all of them, excepting the gsm0503_test_vectors.c, which will be generated automatically by the utils/conv_gen.py in the next commit.
The header is currently included this way: #include "conv.h"
And building in separate directory fails: CC conv/gsm0503_test_vectors.o conv/gsm0503_test_vectors.c:25:18: fatal error: conv.h: No such file or directory #include "conv.h" ^ compilation terminated.
This is why I tried to move this header to the global include directory. According to received feedback from Harald and Sylvain, this approach isn't good and I need to find another one.
Any suggestions how to make the conv/gsm0503_test_vectors.c able "to see" the conv.h header?
With best regards, Vadim Yanitskiy.
On 29. Apr 2017, at 16:09, Vadim Yanitskiy axilirator@gmail.com wrote:
Hi all,
Hi!
conv/gsm0503_test_vectors.c:25:18: fatal error: conv.h: No such file or directory #include "conv.h" ^ compilation terminated.
This is why I tried to move this header to the global include directory. According to received feedback from Harald and Sylvain, this approach isn't good and I need to find another one.
Any suggestions how to make the conv/gsm0503_test_vectors.c able "to see" the conv.h header?
I didn't see this error in the jenkins log. But two things are likely:
* gsm0503_test_vectors.c is compiled before the header is generated (though unlikely here)
* build dir != src dir. So the "conv.h" is not in the srcdir but the builddir?
holger
Thanks for response!
I didn't see this error in the jenkins log. But two things are likely:
- gsm0503_test_vectors.c is compiled before the header is generated
(though unlikely here)
- build dir != src dir. So the "conv.h" is not in the srcdir but the
builddir?
It seems, I already found one solution. You're right, "build dir != src dir" was the problem, so I added this:
conv_conv_gsm0503_test_CPPFLAGS = \ $(AM_CPPFLAGS) \ -I$(top_srcdir)/tests/conv
And now everything is fine!
With best regards, Vadim Yanitskiy.
2017-04-30 14:47 GMT+07:00 Holger Freyther holger@freyther.de:
On 29. Apr 2017, at 16:09, Vadim Yanitskiy axilirator@gmail.com wrote:
Hi all,
Hi!
conv/gsm0503_test_vectors.c:25:18: fatal error: conv.h: No such file or directory #include "conv.h" ^ compilation terminated.
This is why I tried to move this header to the global include directory. According to received feedback from Harald and Sylvain, this approach isn't good and I need to find another one.
Any suggestions how to make the conv/gsm0503_test_vectors.c able "to see" the conv.h header?
I didn't see this error in the jenkins log. But two things are likely:
- gsm0503_test_vectors.c is compiled before the header is generated
(though unlikely here)
- build dir != src dir. So the "conv.h" is not in the srcdir but the
builddir?
holger
On 30. Apr 2017, at 10:02, Vadim Yanitskiy axilirator@gmail.com wrote:
It seems, I already found one solution. You're right, "build dir != src dir" was the problem, so I added this:
conv_conv_gsm0503_test_CPPFLAGS = \ $(AM_CPPFLAGS) \ -I$(top_srcdir)/tests/conv
And now everything is fine!
We generate "conv.h" and put it into the source directory? From 10.000 miles aways it sounds a bit odd (at least for checkout from git, make dist would be a different topic).
holger
We generate "conv.h" and put it into the source directory?
Actually, no. We aren't generate the "conv.h". It's written manually and contains the conv_test_vector structure definition and the do_check() function definition.
One was introduced by: https://gerrit.osmocom.org/#/c/1627/ so now the same test logic is used in two different tests (both conv and conv_gsm0503) without code duplication.
Don't you confuse it with the "gsm0503.h", which is exactly generated by the "utils/conv_gen.py"?
With best regards, Vadim Yanitskiy.
2017-05-01 2:56 GMT+07:00 Holger Freyther holger@freyther.de:
On 30. Apr 2017, at 10:02, Vadim Yanitskiy axilirator@gmail.com wrote:
It seems, I already found one solution. You're right, "build dir != src
dir"
was the problem, so I added this:
conv_conv_gsm0503_test_CPPFLAGS = \ $(AM_CPPFLAGS) \ -I$(top_srcdir)/tests/conv
And now everything is fine!
We generate "conv.h" and put it into the source directory? From 10.000 miles aways it sounds a bit odd (at least for checkout from git, make dist would be a different topic).
holger
On Mon, May 01, 2017 at 03:41:03AM +0700, Vadim Yanitskiy wrote:
We generate "conv.h" and put it into the source directory?
Actually, no. We aren't generate the "conv.h". It's written manually and contains the conv_test_vector structure definition and the do_check() function definition.
written manually? You mean committed in gerrit, right?
One was introduced by: https://gerrit.osmocom.org/#/c/1627/ so now the same test logic is used in two different tests (both conv and conv_gsm0503) without code duplication.
We tend to put all headers used from several locations in openbsc/openbsc/include/openbsc/ (as noinst_HEADERS in the Makefile.am). To #include, you would use something like #include <openbsc/conv.h>.
Don't you confuse it with the "gsm0503.h", which is exactly generated by the "utils/conv_gen.py"?
Loosely related: some time back I modified some generation code to put generated C files in the builddir, adding -I$(builddir) to be able to find them from srcdir... I think it was this one I fixed.
~N
Hi,
written manually?
Yes. Just look at content of this header file.
We tend to put all headers used from several locations in openbsc/openbsc/include/openbsc/ (as noinst_HEADERS in the Makefile.am). To #include, you would use something like #include <openbsc/conv.h>.
Yeah, I tried to put one into include/osmocom/tests/, but Harald and Sylvain voted against this approach. So I decided to go this way.
With best regards, Vadim Yanitskiy.
2017-05-02 17:52 GMT+07:00 Neels Hofmeyr nhofmeyr@sysmocom.de:
On Mon, May 01, 2017 at 03:41:03AM +0700, Vadim Yanitskiy wrote:
We generate "conv.h" and put it into the source directory?
Actually, no. We aren't generate the "conv.h". It's written manually and contains the conv_test_vector structure definition and the do_check() function definition.
written manually? You mean committed in gerrit, right?
One was introduced by: https://gerrit.osmocom.org/#/c/1627/ so now the same test logic is used in two different tests (both conv and conv_gsm0503) without code duplication.
We tend to put all headers used from several locations in openbsc/openbsc/include/openbsc/ (as noinst_HEADERS in the Makefile.am). To #include, you would use something like #include <openbsc/conv.h>.
Don't you confuse it with the "gsm0503.h", which is exactly generated by the "utils/conv_gen.py"?
Loosely related: some time back I modified some generation code to put generated C files in the builddir, adding -I$(builddir) to be able to find them from srcdir... I think it was this one I fixed.
~N
Hi Vadim,
On Wed, May 03, 2017 at 03:19:03AM +0700, Vadim Yanitskiy wrote:
We tend to put all headers used from several locations in openbsc/openbsc/include/openbsc/ (as noinst_HEADERS in the Makefile.am). To #include, you would use something like #include <openbsc/conv.h>.
Yeah, I tried to put one into include/osmocom/tests/, but Harald and Sylvain voted against this approach. So I decided to go this way.
The difference is:
* openbsc doesn't install any headers, and thus all 'include/openbsc' headers are local to the program * libosmocore isntalls all headers, and thus all 'include/osmocom' headers are installable
So if you want to have private header files in libosmcoore (or any other library) you have to put them somewhere else, e.g. in the 'src' directory, as it is already done at several other places.
Hi Harald,
The difference is:
- openbsc doesn't install any headers, and thus all 'include/openbsc'
headers are local to the program
- libosmocore isntalls all headers, and thus all 'include/osmocom'
headers are installable
It is reasonable, and I support this idea. But anyway we have some noinst_HEADERS in include/Makefile.am, they are:
noinst_HEADERS = \ osmocom/core/timer_compat.h \ osmocom/gsm/kasumi.h osmocom/gsm/gea.h
So why they are among with other installable headers? Are there any reasons to keep them here?
So if you want to have private header files in libosmcoore (or any other library) you have to put them somewhere else, e.g. in the 'src' directory, as it is already done at several other places.
I think, you already pointed the strongest reason, why this header should be outside the include/ directory: because it only needed during unit tests, and nowhere else. And I absolutely agree with you.
Now the problem is solved, and this discussion should be closed.
With best regards, Vadim Yanitskiy.
2017-05-03 3:36 GMT+07:00 Harald Welte laforge@gnumonks.org:
Hi Vadim,
On Wed, May 03, 2017 at 03:19:03AM +0700, Vadim Yanitskiy wrote:
We tend to put all headers used from several locations in openbsc/openbsc/include/openbsc/ (as noinst_HEADERS in the
Makefile.am).
To #include, you would use something like #include <openbsc/conv.h>.
Yeah, I tried to put one into include/osmocom/tests/, but Harald and
Sylvain
voted against this approach. So I decided to go this way.
The difference is:
- openbsc doesn't install any headers, and thus all 'include/openbsc' headers are local to the program
- libosmocore isntalls all headers, and thus all 'include/osmocom' headers are installable
So if you want to have private header files in libosmcoore (or any other library) you have to put them somewhere else, e.g. in the 'src' directory, as it is already done at several other places. --
- Harald Welte laforge@gnumonks.org
http://laforge.gnumonks.org/
================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
-
Harald Welte -
Holger Freyther -
Neels Hofmeyr -
Vadim Yanitskiy