Embox build system should generate absolute paths

[GoogleCodeExporter]

See summary. Otherwise it's impossible to build 3rd-party libs which have 
complex build systems with various levels of changing the current directory.

E.g. stuff like "-I./src/include -I./src/arch/arm/include 
-I./build/base/src-gen/include" in CFLAGS is no-go.

Original issue reported on code.google.com by an...@korobeynikov.info on 3 Oct 2013 at 12:05

[GoogleCodeExporter]

Original comment by Anton.Bo...@gmail.com on 3 Oct 2013 at 12:11

[GoogleCodeExporter]

The variable containing absolute include paths already exists in Embox build 
system and is already heavily used in driving third party build systems. It is 
named EMBOX_EXPORT_CPPFLAGS. You can find it's usage in several builders 
located in $(ROOT_DIR)/third_party. E.g. qt, gcc, samba, stlport, zeromq to 
name a few.

Original comment by fsul...@gmail.com on 9 Oct 2013 at 9:23

[GoogleCodeExporter]

This is not true, unfortunately. Here is the contents of EMBOX_EXPORT_CPPFLAGS 
for me:

-D__EMBOX__ -D"__impl_x(path)=<../path>" -imacros ./build/base/src-gen/config.h 
-I/home/asl/ti/embox/./src/include -I/home/asl/ti/embox/./src/arch/arm/include 
-I/home/asl/ti/embox/./build/base/src-gen/include 
-I/home/asl/ti/embox/./build/base/src-gen/src/include 
-I/home/asl/ti/embox/./build/base/src-gen/src/include 
-I/home/asl/ti/embox/./build/base/src-gen/src/arch/arm/include 
-I/home/asl/ti/embox/./platform/olimex/include 
-I/home/asl/ti/embox/./src/compat/linux/include 
-I/home/asl/ti/embox/./src/compat/posix/include -nostdinc -MMD -MP

Note the -imacros stuff.

Also, EMBOX_EXPORT_CFLAGS is empty for me

Original comment by an...@korobeynikov.info on 9 Oct 2013 at 12:39

[GoogleCodeExporter]

What is not true? :) It is sufficient to drive all the mentioned build systems, 
which by the way are of various natures.
The flags are first filtered to get rid of different crap like -imacros you 
mentioned  and __impl_x, which you will find troubles forwarding (there is an 
issue to get rid of it completely in Embox). Then they are merged with CFLAGS 
for C and CXXFLAGS for C++, which are in turn also filtered from some 
inappropriate flags. You can see the whole procedure in any driver's Makefile, 
let's take for reference $(ROOT)/third_party/samba/Makefile.
When I start with porting new library I usually take some existent port and do 
some find/replace stuff. You can find the recent example of such an operation 
for QPid port which I'm working on now: 
https://code.google.com/p/embox/source/detail?r=11132
If you find this experience valueable and have any questions I will be happy to 
come up with answers.

Original comment by fsul...@gmail.com on 9 Oct 2013 at 1:18

[GoogleCodeExporter]

The crap is all those tricks to "fix" the broken system. In general, it's not 
possible to get rid of __impl_x because various embox headers (e.g. cmd.h) 
depend on them. And no, all those order.mk fragments and stubs are not the 
proper way of doing things.

The exported cflags should *NOT* contain any relative paths. And it should 
*NOT* require any postprocessing period.

Original comment by an...@korobeynikov.info on 9 Oct 2013 at 2:35

• Added labels: Priority-High
• Removed labels: Priority-Medium

[GoogleCodeExporter]

Unfortunately, all this "crap" is the only way to make things work in available 
time. It is certainly better to be reach and healthy than poor and sick, this 
is your logic - who doubts it is true? It is just unreal! I don't say all of it 
is good and actually don't offer to reuse all of them. I only offered you to 
filter flags and offered help if you need it.
Now let's go step by step.
Regarding all these order.mk stuff - it was supposed be removed in the future 
versions of build system, when it will be able to handle these kind of 
dependencies by itself, so there is no overhead. But the problem is, I'm 
waiting for this shiny new build system since I work here and it is still not 
there.
Regarding "stubs" - I do not understand, what you mean exactly and why do you 
think that what you mean is actually crap. If you mean having stub functions 
for missing functionality, then I believe this is the way things should be done.
Regarding __impl_x - it is necessary to get rid of it because the "<" and ">" 
signs in it's body confuse shells and are difficult if not impossible to 
forward. Moreover, I see no any more or less significant reason to keep it.
Regarding filtering flags - I strongly believe that it is the way it should be 
done, because every dependent build system requires it's own set of flags and 
it is build system driver who should decide which to keep, which to remove and 
which to add. I have seen no system where flags would be directly forwarded, 
there are solutions like gentoo, but they are different. For example, internal 
embox flags are too strict and typical library requires more relaxed settings.
Regarding relative path it -imacros - here I agree - this is wrong, but it is 
negligible and doesn't break anything.

So after all this I still don't get it - what's your point, cowboy? I do not 
see constructivism in your criticism. Even if some parts of the system are 
broken - right now we do not have a replacement (or I am not aware of it). I 
offer you to follow my steps. It has the benefit that in the future when build 
systems evolves all the libraries will have to be changed uniformly. But it is 
not clear for me - what do you offer?

Original comment by fsul...@gmail.com on 9 Oct 2013 at 7:38

[GoogleCodeExporter]

> Regarding "stubs" - I do not understand, what you mean exactly and why do you 
think that what you mean is actually crap. If you mean having stub functions 
for missing functionality, then I believe this is the way things should be 
done. Regarding __impl_x - it is necessary to get rid of it because the "<" and 
">" signs in it's body confuse shells and are difficult if not impossible to 
forward. Moreover, I see no any more or less significant reason to keep it.

The problem is - I cannot include, say "embox/cmd.h" from inside 3rd-party app, 
(even if I provided neat embox-aware implementation of various stuff inside) 
because this (and some other headers) relies on it and use it heavily. So I 
need to follow the following weird way:
  - build 3-rd party app and make some functions externally visible. Build the app with filtered CFLAGS
  - Add dummy stubs which basically just include the headers which use __impl_x functionality, do necessary lifting and call the real functions from inside 3rd-party app

All this looks pretty weird. I can provide neat module implementation from 
inside 3rd party app, but I cannot provide app / command. And you're calling 
this sane?

Original comment by an...@korobeynikov.info on 9 Oct 2013 at 7:52

[GoogleCodeExporter]

Yes, I recognize the problem.
Well, I prefer to think about it in the following way: 3rd party parts should 
be kept as vanilla as possible (otherwise these are not 3rd party parts 
anymore), therefore it is desirable that they are not embox-aware (but there 
may be exceptions - I don't know you exact app).
What you described of course solves the problem, I think this is how we usually 
do this now (export some sort of main() function from the application, then 
call it from the command implemented in Embox build system). It doesn't look so 
awful in my opinion as you describe it.
I actually see no reason why the command cannot be implemented inside 3rd party 
component, in my opinion the easiest way to allow it is to resolve issue 517 
https://code.google.com/p/embox/issues/detail?id=517 in part of __impl_x, i.e. 
get rid of it completely. Alternatively you may try to define this __impl_x 
macros directly after filtering in your build system driver. I believe the 
descendants will forgive us :) But I may warn you - I had some troubles with 
forwarding angle braces, so it may not always work.

Regarding this issue - I see the relevant part now is only relative path in 
-imacros and in my opinion it is negligible. Is there anything else in "dry 
residue"?

Original comment by fsul...@gmail.com on 9 Oct 2013 at 8:30