[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] Special build types, e.g. gcov

From: Greg Chicares
Subject: Re: [lmi] Special build types, e.g. gcov
Date: Thu, 30 Oct 2014 00:43:28 +0000
User-agent: Mozilla/5.0 (Windows NT 5.1; rv:24.0) Gecko/20100101 Thunderbird/24.6.0

On 2014-10-29 22:56Z, Vadim Zeitlin wrote:
> On Wed, 29 Oct 2014 18:19:04 +0000 Greg Chicares <address@hidden> wrote:
> GC> The lmi makefiles provide various special-purpose build types:
> GC>   grep build_type make
> GC> including one for gprof, so gcov should be easy to add. My first
> GC> thought would be to add it in parallel with (and distinct from)
> GC> gprof; is that the usual practice, or do most people use a single
> GC> build for both gprof and gcov, combining all their flags together?
>  To be honest, I don't use gcov that much, so I don't know how people use
> it usually. But I think it's more logical to keep separate gcov and gprof
> builds and maybe add gcov_and_prof one later if needed. I'm going to do
> this soon if you have no objections.

Sure, if you want to make a patch for this, thank you.

> GC> BTW, I hadn't exercised lmi's 'so_test' build type since adding
> GC> the GUI tests, so this seemed like a good time to try it:
> GC> 
> GC>   make --jobs=16 all build_type=so_test USE_SO_ATTRIBUTES=1  >../log 2>&1
> GC> /MinGW_/bin/g++  -o wx_test.exe main_wx_test.o wx_test_about_version.o 
> wx_test_benchmark_census.o wx_test_calculation_summary.o 
> wx_test_config_settings.o wx_test_create_open.o wx_test_default_input.o 
> wx_test_default_update.o wx_test_expiry_dates.o wx_test_extract.o 
> wx_test_input_sequences.o wx_test_input_validation.o wx_test_paste_census.o 
> wx_test_pdf_create.o wx_test_validate_output.o lmi_msw_res.o skeleton.dll 
> liblmi.dll -L . -L /opt/lmi/local/lib -L /opt/lmi/local/bin  -L 
> /opt/lmi/local/lib
> GC> -lwx_mswu-3.1-i686-pc-mingw32 -mwindows    -lexslt -lxslt -lxml2        
> -Wl,-Map,wx_test.exe.map -Wl,--disable-auto-import
> GC> 
> wx_test_default_input.o:C:/opt/lmi/MinGW-20090203/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/ext/new_allocator.h:62:
>  undefined reference to `tn_range<calendar_date, date_trammel<calendar_date> 
> >::value() const'
> GC> 
> wx_test_default_input.o:C:/opt/lmi/MinGW-20090203/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/ext/new_allocator.h:62:
>  undefined reference to `datum_string::value() const'
> GC> 
> GC> We could, of course, decide that wx_test needn't be built this way,
> GC> but this is such a small problem that it seems better to fix it.
> GC> I think the easiest way is to use this:
> GC>   yare_input::yare_input(Input const& z)
> GC> which turns an Input instance into something whose members are
> GC> directly useful--e.g.:
> GC>     calendar_date                     EffectiveDate                   ;
> GC>     std::vector<double>               GeneralAccountRate              ;
> GC> Would you mind doing that?
>  I did it, but I had a couple of problems:

Sorry, I was too optimistic.

You can always get a std::string from an any_member<>, and I really
think that'll be enough to write these simple tests. I've confirmed
that these lines do compile and link:

    std::string const effective_date = cell["EffectiveDate"].str();
    std::string const general_account_date = cell["GeneralAccountRate"].str();

So do these lines, which may possibly DTRT for the effective-date test:

    #include "value_cast.hpp"

    std::string const effective_date_jdn_str = cell["EffectiveDate"].str();
    std::string const first_of_month_jdn_str = 
    LMI_ASSERT_EQUAL(effective_date_jdn_str, first_of_month_jdn_str);

but you can certainly write it in a less ugly manner.

> 1. I still had to add LMI_SO to yare_input class declaration, otherwise I
>    was just getting similar errors for it instead of the errors above.

Oh. I didn't anticipate that...

>    Notice that I was able to fix the latter one of those easily, just by
>    adding LMI_SO to datum_string class too.

LMI_SO is dll[ex|im]port for msw compilers that need it, but perhaps
more importantly it's the ELF visibility attribute. I don't know
whether the latter ever really caught on, but in any case it seems
good to me to promote encapsulation.

But here we expose first one class, then another...

The farmer takes a wife
The wife takes the child
The rat takes the cheese
...and pretty soon everything's "encapsulated" in a single ocean.

>    But the one with tn_range<>
>    was less obvious and I couldn't fix it quickly and, as you advised to
>    switch to yare_input anyhow, I didn't spend more time on it.

Yes, sorry, it's a dead end.

> 2. I was not sure how to format GeneralAccountRate on output, so I decided
>    to just output all the elements of the vector, but this is probably not
>    the right thing to do as it results in the output like "0.06, 0.06,
>    [52 more times], 0.06" instead of just "0.06" as before. Unfortunately
>    I don't know how to recover the original string form from the vector, I
>    wonder if you already know the answer to this because I'm a bit lost in
>    all this conversion code.

The code I wrote above should give you the original string.
I suppose that's what's wanted on output.

> 3. Worst of all, the test doesn't work any more when built with MinGW
>    (while working just fine with MSVC): it fails with the error that
>    the vector is empty.

So just do this
    std::string const general_account_date = cell["GeneralAccountRate"].str();
and don't try to get it as a vector. I imagine the string is good
enough for this test.

Or you could read the rest of the message, but the last person who
did that went quite mad.

>    I'm completely lost as to how is this possible,
>    so I'm going to try rebuilding without optimizations to be able to debug
>    the code as something seems to be going seriously wrong inside
>    yare_input ctor.

Well, it looks like this LMI_MSC code should do its intended job:

yare_input::yare_input(Input const& z)
// TODO ?? This temporarily works around a deeper defect. See:
//   http://lists.nongnu.org/archive/html/lmi/2009-02/msg00074.html
#if defined LMI_MSC
#endif // defined LMI_MSC

...but when you need the heavy artillery, do this:

  wxBusyInfo info
      .Title("<b>Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn</b>")

to summon the utmost abomination:


You'll suffer 999 hit points damage, but you have a 15% chance of
getting a nonempty vector.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]