quickfix-developers

[Quickfix-developers] QuickFIX 1.4.1

[Oren M. <ore...@ya...>]

QuickFIX 1.4.1 is now available here:
http://quickfix.thoughtworks.com/download.html

release notes are here:
http://sourceforge.net/project/shownotes.php?release_id=151463

Mostly bug fixes and compilation fixes.  If you has
trouble getting 1.4.0 working, this one probably
addresses your problem.  Also a fix for repeating
groups is in this version.

Experimental feature for displaying C++ call stack
after a crash can also be optionally enabled.  This
adds overhead and should be enabled if you are
experiencing a strange crash and need to know where it
is happening.  If your system provides you with a
coredump, you should compile with -g instead of using
this feature.

Most of the patches for this version came from various
contributors.  CONTRIBUTORS and THANKS files have been
added to the repository, acknowleding people who have
helped the project.  It isn't complete yet and I know
I'm missing several of you.


__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - File online, calculators, forms, and more
http://tax.yahoo.com

Re: [Quickfix-developers] QuickFIX 1.4.1

[Joerg T. <Joe...@ma...>]

Oren Miller wrote:
> QuickFIX 1.4.1 is now available here:
> http://quickfix.thoughtworks.com/download.html

Thanks Oren for building this release. Now I can compile without errors. And more important:
The runtime problems (SIGRTMIN and SIGABRT) with 1.3.2 have gone. Now my Java process starts
and I can continue to develop the prototype applications. Many thanks again!!


Below there are some minor issues for purists ;-)

$ make

../Utility.h:118: warning: `const char*FIX::EOL' defined but not used

	This is seen at several places. IMHO, the std::endl could be used if
	the flush done by this construct does not matter.
	(See stdc++ doc:

>> Some people also believe that sending endl down an output stream only writes a newline. This is incorrect; after a newline is written, the buffer is also flushed. Perhaps this is the effect you want when writing to a screen -- get the text out as soon as possible, etc -- but the buffering is largely wasted when doing this to a file:

>>   output << "a line of text" << endl;
>>   output << some_data_variable << endl;
>>   output << "another line of text" << endl;
	
	The std::endl should also send '\r\n' on Windows, but I am not sure.)

	

org_quickfix_MySQLLog.cpp:127:19: warning: no newline at end of file
org_quickfix_MySQLLogFactory.cpp:125:19: warning: no newline at end of file

	These probably slipped through to the release.


$ make install

rm -rf /opt2/QuickFIX/linux/1.4.0/include/quickfix
mkdir /opt2/QuickFIX/linux/1.4.0/include/quickfix
mkdir: cannot create directory `/opt2/QuickFIX/linux/1.4.1/include/quickfix': No such file or directory

To fix this I added in src/C++/Makefile.am the line 116 below:

     114 install-exec-local: *.h
     115     rm -rf $(includedir)/quickfix
     116     -mkdir $(includedir)
     117     mkdir $(includedir)/quickfix
     118     mkdir $(includedir)/quickfix/include
     119     cp *.h $(includedir)/quickfix/include

The include files then install into

	/opt2/QuickFIX/linux/1.4.0/include/quickfix/include

which looks at little bit strange (double include).

IMHO, the src/C++/Makefile.am should be changed in the following way

- Move all *.h files from
	
	libquickfix_la_SOURCES = ...

   to

	pkginclude_HEADERS = ...

- Drop the install-local / uninstall-local target altogether.

This install the include file into

	/opt2/QuickFIX/linux/1.4.0/include/quickfix

and they can be accessed using

	#include <quickfix/...>

which seems to more standard than using

	#include "quickfix/include/..."

as in the examples. Of course, after doing that, QuickFIX probably has to be installed to be used by the
examples (and the tests).

In addition, it would be nice to install the generated quickfix.jar into the lib directory.
Change src/java/Makefile.am:

- Add

javadir = $(libdir)
java_DATA = ../../lib/quickfix.jar

- Drop the install-local / uninstall-local targets.


Anyway, I just start to understand autotool so my suggestions are just starting points.

Oren, could you please comment on these issues?

Thanks, Jörg

-- 
Joerg Thoennes
                                http://macd.com
Tel.: +49 (0)241 44597-24      Macdonald Associates GmbH
Fax : +49 (0)241 44597-10      Lothringer Str. 52, D-52070 Aachen

Re: [Quickfix-developers] QuickFIX 1.4.1

[Oren M. <ore...@ya...>]

>> ../Utility.h:118: warning: `const char*FIX::EOL' defined but not used

>> This is seen at several places. IMHO, the std::endl could be used if
>> the flush done by this construct does not matter.
>> (See stdc++ doc:

Agreed.  I believe this is only used in the toXML method, and I'm not sure why.  Looks like a lapse.

>> org_quickfix_MySQLLog.cpp:127:19: warning: no newline at end of file
>> org_quickfix_MySQLLogFactory.cpp:125:19: warning: no newline at end of file
>> These probably slipped through to the release.

Yeah, these will be fixed.

$ make install

>> rm -rf /opt2/QuickFIX/linux/1.4.0/include/quickfix
>> mkdir /opt2/QuickFIX/linux/1.4.0/include/quickfix
>> mkdir: cannot create directory `/opt2/QuickFIX/linux/1.4.1/include/quickfix': No >> such file or directory
>> To fix this I added in src/C++/Makefile.am the line 116 below:

I havn't seen this before, but I can see how some systems might need it.  I guess it depends on how your mkdir works.


>> /opt2/QuickFIX/linux/1.4.0/include/quickfix/include
>> which looks at little bit strange (double include).

Yeah, this is sort of a result of windows having no standard for installing header and library files, so they are generally put in a local directory.  I didn't want to muddle the root quickfix directory, hence the include directory which then had to be carried over to *nix for portability.  I would like it to work like you suggest, but will need to reorganize how headers are installed in windows.  I'm thinking of creating an "output" directory under the root quickfix directory.  There would then be another "quickfix" directory under output which would contain the include files (and a directory for the lib and bin files).  That way under windows people can put quickfix\output in the include path, and we can then do things more normally under *nix.  

Any input on how this problem is normally handled would be helpful.

>> In addition, it would be nice to install the generated quickfix.jar into the lib directory.
>> Change src/java/Makefile.am:

Yeah, I didn't really know what standard procedure there was for installing jar files.  Sounds like a good place to me.





---------------------------------
Do you Yahoo!?
Yahoo! Tax Center - File online, calculators, forms, and more

Re: [Quickfix-developers] QuickFIX 1.4.1

[Joerg T. <Joe...@ma...>]

Oren Miller wrote:

> I havn't seen this before, but I can see how some systems might need 
> it.  I guess it depends on how your mkdir works.

UNIX mkdir cannot make multiple path elements at once unless you specify -p. In this
case, it could not make ".../include/quickfix" because "../include" did not exist.

>  >> /opt2/QuickFIX/linux/1.4.0/include/quickfix/include
>  >> which looks at little bit strange (double include).
> 
> Yeah, this is sort of a result of windows having no standard for 
> installing header and library files, so they are generally put in a 
> local directory.  I didn't want to muddle the root quickfix directory, 
> hence the include directory which then had to be carried over to *nix 
> for portability.  I would like it to work like you suggest, but will 
> need to reorganize how headers are installed in windows.  I'm thinking 
> of creating an "output" directory under the root quickfix directory.  
> There would then be another "quickfix" directory under output which 
> would contain the include files (and a directory for the lib and bin 
> files).  That way under windows people can put quickfix\output in the 
> include path, and we can then do things more normally under *nix. 
> 
> Any input on how this problem is normally handled would be helpful.

Since I do not work on Windows, I cannot contribute here. According to the
automake docs, the are two prefixes for installing include files:

	include_HEADERS
	pkginclude_HEADERS

If you use the first one, all headers are installed in

	$(prefix)/include

and in the second case in

	$(prefix)/include/quickfix
#inclu
(Quickfix is here the package name.) Together with '#include <quickfix/...' this
would be the best solution if you could make it fit for Windows. To make this work,
all includes of the kind "#include "quickfix/include/..." should be changed to
the <quickfix/...> style. If you say in Windows "-I<somedir>\include", it should also
find '#include <quickfix/...>' if the compiler translates the file separators.

>  >> In addition, it would be nice to install the generated quickfix.jar 
> into the lib directory.
>  >> Change src/java/Makefile.am:
> 
> Yeah, I didn't really know what standard procedure there was for 
> installing jar files.  Sounds like a good place to me.

Yes, there wasn't a standard one. I invented it ;-) See "info automake", Generalities::Uniform:

 >     Sometimes the standard directories--even as augmented by Automake--
 > are not enough.  In particular it is sometimes useful, for clarity, to
 > install objects in a subdirectory of some predefined directory.  To this
 > end, Automake allows you to extend the list of possible installation
 > directories.  A given prefix (e.g. `zar') is valid if a variable of the
 > same name with `dir' appended is defined (e.g. `zardir').

 >   For instance, until HTML support is part of Automake, you could use
 > this to install raw HTML documentation:

 >     htmldir = $(prefix)/html
 >     html_DATA = automake.html

Writing portable build scripts is a tedious work, I hope I helped you a little bit.

Cheers, Jörg


-- 
Joerg Thoennes
                                http://macd.com
Tel.: +49 (0)241 44597-24      Macdonald Associates GmbH
Fax : +49 (0)241 44597-10      Lothringer Str. 52, D-52070 Aachen