Ticket #543 (new enhancement)

Opened 11 years ago

Last modified 9 years ago

Unable to build against uninstalled version of the library

Reported by: rodolphe.ortalo@… Owned by: mickey
Priority: normal Milestone:
Component: openmoko-libs Version: current svn head
Severity: minor Keywords:
Cc: buglog@… Blocked By:
Blocking: Estimated Completion (week):
HasPatchForReview: yes PatchReviewResult:
Reproducible:

Description

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.)

Attachments

patch-recconf-2007-12-09.patch (50.3 KB) - added by rodolphe.ortalo@… 10 years ago.
recursive configure patch to OM2007.2

Change History

comment:1 Changed 10 years ago by mickey@…

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

comment:2 Changed 10 years ago by 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.

comment:3 Changed 10 years ago by 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?

comment:4 Changed 10 years ago by mickey@…

  • Severity changed from minor to enhancement

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

Changed 10 years ago by rodolphe.ortalo@…

recursive configure patch to OM2007.2

comment:5 Changed 10 years ago by 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.

comment:6 Changed 10 years ago by roh

  • Owner changed from mickey@… to mickeyl

comment:7 Changed 10 years ago by roh

  • Owner changed from mickeyl to mickey

comment:8 Changed 9 years ago by john_lee

  • HasPatchForReview set

comment:9 Changed 9 years ago by mickey

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

Note: See TracTickets for help on using tickets.