Menu

#355 Make fuse a stand alone library & move main entry point to another file

future
open
nobody
None
5
2017-10-11
2016-04-09
No

It is useful for UIs that needs a much more complicated build system to build them and they also need their own event loop. Those UIs will start fuse on another thread and this way evebody is happy. Add also a null UI.

Changes from BogDan Vatra in [#349].

1 Attachments

Related

Patches: #349
Wiki: Fuse 1.2.2 Release Plan
Wiki: Fuse 1.3.0 Release Plan
Wiki: Fuse 1.3.1 Release Plan
Wiki: Fuse 1.3.2 Release Plan
Wiki: Fuse 1.3.3 Plan
Wiki: Fuse 1.3.4 Release Plan
Wiki: Fuse 1.3.5 Release Plan
Wiki: Fuse 1.3.6 Release Plan
Wiki: Fuse 1.3.7 Release Plan
Wiki: Fuse 1.3.8 Release Plan
Wiki: Fuse 1.4.0 Release Plan
Wiki: Fuse 1.4.1 Release Plan
Wiki: Fuse 1.5.0 Release Plan
Wiki: Fuse 1.5.1 Release Plan
Wiki: Fuse 1.5.2 Release Plan
Wiki: Fuse 1.5.3 Release Plan
Wiki: Fuse 1.5.4 Release Plan
Wiki: Fuse 1.5.5 Release Plan
Wiki: Fuse 1.5.6 Release Plan
Wiki: Fuse 1.5.7 Release Plan
Wiki: Fuse 1.6.0 Release Plan
Wiki: Fuse Next Release Plan

Discussion

  • Fredrick Meunier

    Hi BogDan,
    I face similar issues on OS X and also run Fuse in a separate thread and could conceivably migrate to using this scheme to integrate Fuse.

    Could you please add some more information on the purpose of the null UI in this patch?

    Thanks,
    Fred

     
  • BogDan Vatra

    BogDan Vatra - 2016-04-09

    The null ui is needed by external UIs to build fuse library, check diffs from options.dat , fuse.c and menu_data.dat, without building any other UIs, e.g. for Android I can't build SDL or GTK UIs.

     
  • Sergio Baldoví

    Sergio Baldoví - 2016-04-13

    Had a quick look...

    I guess the need of libfuse.a is because BogDan is building Spectacol in two phases: fuse by autotools (configure.ac) and qml UI (main.pro) by some external toolchain. Otherwise I would advise against using of a convenience library.

    configure.ac: The use of AS_HELP_STRING within AC_ARG_WITH for --with-nullui option, would avoid errors like this:
    https://github.com/bog-dan-ro/spectacol/commit/bdba1ce8bf224b4361cd98a599aae2f41c04ada9

    Makefile.am: blank line following trailing backslash (EXTRA_libfuse_a_SOURCES). PTHREAD_LIBS should be added to fuse_LDADD.

    I can't complete the build with NULL UI. There are lots of multiple definitions (e.g., 'ui_error_specific') between widget and null UI. Is widget UI really needed? I think I'm missing something...

     
  • Fredrick Meunier

    I have a similar issue on the Mac though I build all the Fuse source in the OS X build chain/IDE rather than re-use the Fuse Makefiles. When I integrate a new release I need to manually inspect changes to the headers, Makefiles and so on to make the appropriate adjustments to get Fuse to build. On the plus side I get better error messages, static analysis and debugging support than I think I would linking a convenience library.

    If it is just building a library that is then re-linked into the project I still don't get the need for the NULL UI - I would have expected that a real UI would be provided in the platform files and the built library could would be linked to them as the final application binary is linked?

    I think that having Fuse directly supporting being called as a library rather than as the container applicaton would be a good thing as like BogDan I need to provide the platform UI framework with control of the event loop which calls into Fuse code as required.

     
  • BogDan Vatra

    BogDan Vatra - 2016-04-14

    Ah, sorry I forgot to mention that this is a WIP patch and it needs more love from someone who really understands autotools :).

    NULL UI: should replace the widget UI completely, and is needed ONLY to build a dummy fuse executable. If we'll make a libfuse, then null ui is not needed at all, but this means that we need to move all UI to separate project(s) and to separte folder(s).

    @Fredrick Meunier : regarding OSX, Qt has a great support for lots of platforms including OSX (and iOS), if you like we can join forces to make the best Z80 ui ;-)

     
  • Fredrick Meunier

    Thanks BogDan, my goal for Fuse for Mac OS X is to be a completely native application and fully integrate with the platform standards and APIs so I won't be using any cross-platform UI toolkits for the forseeable future.

     
  • BogDan Vatra

    BogDan Vatra - 2016-04-19

    I understand :).

     
  • Philip Kendall

    Philip Kendall - 2016-05-16

    My 2p: Fred's being gently hinting for a long time that it would be nice to make Fuse easier to integrate with other build chains etc, and this is now a second use case. It's certainly something we should look into fairly quickly post v1.2 - exactly how we do it I'm not too bothered about :-)

     
  • BogDan Vatra

    BogDan Vatra - 2016-05-18

    IMHO there are three requirements to get this done:
    * separate the FUSE engine from the UIs
    * move all the UIs to a separate project
    * make fuse a standalone library (or merge it into libspectrum?)

    Regarding the integration/building with other build systems, there are a few things which makes it quite hard at least to build it:
    * in libspectrum you need to first compile an application which is used to generate a perl script which is used to generate libspectrum.h, this (strange) combination is not supported by many build systems
    * it will be also nice to find a way to get rid of all perl scrips

     

    Last edit: BogDan Vatra 2016-05-18
  • Fredrick Meunier

    A null UI has been added in Fuse 1.4.1.

     

Log in to post a comment.