Re: [jazzplusplus-devel] Re: jazzplusplus-devel digest, Vol 1 #43 - 4 msgs

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

On Wednesday 09 June 2004 02:44 am, Rieder wrote:
> In the meantime I got the Jazz++ sources. I installed wxWidgets 2.4.2 for
> Windows. I compiled the library, some wx sample programs and demos and they
> work. I must study yet their tutorial since I'm not familiar with this GUI
> lib...

It's MFC-like.  ;)

> I tried to generate a Makefile with autoconf but got 3 different confusing
> error messages with 3 different versions of these tools (2 cygwin on
> Windows and 1 on SuSE 8.2 Linux). Finally I decided to build a MSVC++ 6.0
> project (+ workspace) from scratch. After some adaptations I could compile
> my first module jazz.cpp. Then I compiled also player.cpp and song.cpp. Now
> I have too many open points to continue work:
>
> Since I did not use autoconf, there is no config.h file, but it gets
> #included. I created a new config.h file to satisfy the existing sources
> and put it into this "mswin" directory I found. Was this correct ?

Correct enough for MSVC++.  That's how Audacity solves this problem.  Now, in 
config.h you must put all defines that are determined by the ./configure 
script on GNU systems.

> What is the sense of this jazzdll.cpp file in the mswin directory ? Is
> there a DLL to be built in the jazz project ?

You'll have to piece this one out, I think.  I don't know what it does.  ;)  
Maybe someone else does?

> I had to #define a JAZZ_DATADIR (I did it in the new config.h) to get
> jazz.cpp compiled. What is the meaning of it and how should it work on
> Windows: as on UNIX or different ?

./configure sets the prefix, or can be passed the prefix on the commandline.  
Usually the prefix is /usr/local, the Jazz binary goes in /usr/local/bin, and 
then there's the JAZZ_DATADIR directory which is determined by ./configure 
based on this prefix.  So, you have an interesting decision to make already.  
Do you want to force Windows users to adhere to a convention that doesn't 
normally apply on Windows?  The convention is a UNIX thing, of course, that 
says /usr/bin get binary applicaitons, /usr/lib gets libraries, /usr/share 
gets shared data, and so forth.  /usr/local/* the same, but the "local" means 
something else.  I would say you don't want to force this onto Windows users, 
because it wouldn't allow them to install Jazz completely on different 
partitions or in different places.  So you'll have to come up with something 
else for this.  ;)  Personally, I'd prefer if you came up with something we 
could use on Linux too and replace this #define with something more portable 
and more useful.

> What are the wxProperty... things ? You can only use them if macro
> "wxUSE_PROPSHEET" is not 0. In the file lib/msw/wx/setup.h it is #defined
> to be 0! I had to add "$(WXWIN)/lib/msw" to my inlucde path - like in the
> wxWidgets sample programs - to get things compiled. I had to change the
> value to 1 in the wxWidgets source, but I guess it's not the way it is
> meant by the inventors. But what is correct ? Not to use wxProperty...
> classes in Windows programs ??

Beats me

> The most confusing things are these wx_... macros. For example I started to
> change wx_msw into __WXMSW__. I believed that wx_msw might be the wxWindows
> old way and __WXMSW__ the new way (see wxWidgets platform.h). Then I
> discovered other such macros like wx_xt and wx_xview. I asked myself: why
> should you be able to compile the jazz sources with so many old macros and
> I not ? Did you generate these macros with autoconf/automake and I am
> missing something ?

Hm.  I think you're actually supposed to use __MSW__, but I could be wrong 
about that.  Lemme do a quick check...  Looks like you're supposed to use 
__WXMSW__ to check to see if we're compiling on Windows.  If you absolutely 
need to know, you can use __WIN32__ to see if we're compiling on win9x or 
winME.  I'm thinking you should eliminate these other macros and see what 
happens.  ;)  Or, since you've got Cygwin installed, grep the wx sources with 
the other macros and see what the comments around the macros say.

> The amount of specific code for Windows I saw up to now was frightening! I
> had the hope that the OS interface is covered by wxWidgets (neary
> completely). Isn't that the case ?

Yes and no.  To get it working for Windows, you *should* be able to eliminate 
most of the Windows specific code.  You might have to write the PortMIDI 
driver, finally, to get the MIDI working again.  I would suggest that you 
consider doing that and running fluidsynth or timidity as a softsynth, since 
that's the direction we're going.  That is, if you find you can't get the 
existing MIDI code working within say an hour or two of fiddling with it.  
PortMIDI is pretty straightforward and should theoretically only take a 
couple of hours to get working with Jazz, and like I said, it's where we want 
to go.  As far as the UI, just do what we did already.  If it doesn't 
compile, disable it from the code (use #if 0 or comment blocks or something).  
Get it building as quickly as possible.  It builds and runs under Linux using 
no platform specific GUI code, just wxWidgets for GUI.  Uses the OSS midi 
driver, I think.  Might use alsa, someone was working on it awhile ago.  
Yeah, I think it uses alsa, now that I think about it.  Anyway, the only 
platform specific code being used under Linux right now is the sound backend, 
and since we haven't even touched it, the Windows sound backend should 
*still* work fine.  So disable anything that doesn't compile, refer to the 
Makefile.am files for the source files that need to be in the project, and 
make the config.h file in win/ contain all the macros that are determined by 
./configure, get it building, and tell us what works and what doesn't work.  
Then we can tell you if it doesn't work in Linux either and is part of the 
overall porting work, or if it *does* work in Linux and needs special 
attention for Windows.

I really appreciate you taking the time to work on this, I can't say enough 
thank you.  :)

Dave

> Looking forward to your answers
> Harald
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: GNOME Foundation
> Hackers Unite!  GUADEC: The world's #1 Open Source Desktop Event.
> GNOME Users and Developers European Conference, 28-30th June in Norway
> http://2004/guadec.org
> _______________________________________________
> jazzplusplus-devel mailing list
> jaz...@li...
> https://lists.sourceforge.net/lists/listinfo/jazzplusplus-devel

-- 
Visit my website!
http://www.davefancella.com/?event=em

To whom the mornings are like nights,
What must the midnights be!
		-- Emily Dickinson (on hacking?)