Unable to build against uninstalled version of the library

[rodolphe.ortalo@…]

The new libmokojournal/ subdir does not follow the same directory structure as
the other ones. Particularly, there is a libmokojournal/src/ subdir. The public
headers exported by this sublib (moko-journal.h and moko-time.h) are located in
this libmokojournal/src/ subdir.
With this source directory structure, it is not possible to build against a
_uninstalled_ version of the library. Client app uses
"libmokojournal/moko-journal.h" to include the header file (for example, see
applications/openmoko-dialer/src/dialer-window-history.c ).
Former components of openmoko-libs did not exhibit that structure (see, for
example, libmokoui/moko-pixmap-button.h ) and allowed me to build apps against
uninstalled version of openmoko-libs (see other patch in bugzilla #530 and the
-uninstalled.pc).

It would be nice to get back this ability for me, but that would imply moving
the public headers out of libmokojournal/src/ to put them in libmokojournal/. Do
you think that's possible? (You would then need something like AM_CPPFLAGS =
-I.. in libmokojournal/src/Makefile.am I guess.)

[mickey@…]

Can't we do this with uninstalled.pc files rather than moving directories and files?

[rodolphe.ortalo@…]

I don't think (hence the bug the report).
With an -uninstalled.pc file, you can only adjust compiler/linker directives
(most notably -I../path/) for the uninstalled case. If the client source code
refers to headers with a specific path via #include, the headers won't be found
because they do not have the same path in the library source code.

[rodolphe.ortalo@…]

I looked again today and, apparently, inside OM2007.2 the #include conventions
for source files have changed. Now, I see things like, for example, #include
<moko-journal.h> in the dialer2 source code.
If apps source files do not use a library prefix directly, then, IMHO this bug
report is now pointless (it should be possible to solve things using uninstalled
pc files) - but I've not yet tried to update my own full autoconf attempt to the
latest OM2007.2 source tree so that's just a theoretical statement for the moment.
(We are lucky in fact, as there was apparently a similar issue with other libs.)

BTW, is there still interest in a recursive autoconf script?

[mickey@…]

Yes, still interested in that! Let's collaborate on that. Flagging it as
enhancement though.

[rodolphe.ortalo@…]

recursive configure patch to OM2007.2

[rodolphe.ortalo@…]

Browse the above patch before considering for inclusion:

• a few source files are touched (primarily for #include adjustements)
• major apps are not built currently (mediaplayer2, appmanager), primarily due

to hard to setup dependencies on a standard Ubuntu.

• artwork files may not be installed in the correct place
• the "start-softmoko" script is certainly perfectible (esp. wrt GNOME setup and

finding theming files inside the xoo window).
However, I have already followed several SVN updates with minimal effort. So the
build system is probably more or less adequate for a host-based development
environment (without any qemu emulation).

I welcome any ideas to push the idea further.

[mickey]

I think we should just apply this patch, if it still applies.