Mingw 64 bit build

[Stephen Leake-3]

I've built nvm.msys2-mingw-64 with Mys2/MingW64 64 bit. It passes all tests
except one func test (empty_environment) and some extra tests.

I need to test that branch on a Unix box (I have Debian and Cygwin),
since most of the changes are in '#ifdef Windows' areas.

See INSTALL_windows_msys2_64.txt for tools install; there is also
INSTALL_windows_msys2_32.txt, which is very similar, but has "32"
instead of "64" in lots of places. Having two different files makes it
easier to cut and paste the commands.

--
-- Stephe

_______________________________________________
Monotone-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/monotone-devel

[Markus Wanner-2]

Stephen,

On 05/03/2014 03:54 PM, Stephen Leake wrote:
> I've built nvm.msys2-mingw-64 with Mys2/MingW64 64 bit. It passes all tests
> except one func test (empty_environment) and some extra tests.

Cool, thanks.

What goes wrong in empty_environment? That one works on Msys 1.0.

> I need to test that branch on a Unix box (I have Debian and Cygwin),
> since most of the changes are in '#ifdef Windows' areas.

I just tried: There are a couple of places where Unix needs an argument
that you've commented out. Please revert those.

Also, I'm not a fan of the cast to void hack. That clutters the source
code quite a bit - especially when you need additional ifdefs to filter
based on platform. I'd rather disable that warning.

Please also teach your editor to not re-indent code you didn't touch.
That greatly eases review.

> See INSTALL_windows_msys2_64.txt for tools install; there is also
> INSTALL_windows_msys2_32.txt, which is very similar, but has "32"
> instead of "64" in lots of places. Having two different files makes it
> easier to cut and paste the commands.

I appreciate your efforts to document the build process. However, please
keep in mind that we don't provide half the amount of instructions on
building on any other OS. Already before those additions, I felt the
urge to merge, simplify and reduce the information into one file.

I think exact commands should go into a script or on the wiki, if yo
want. In the source tree, I'd say a single INSTALL_windows.txt showing
different build options and outlining special considerations for Windows
should suffice. As it stands, an average Windows user would need a guide
on how to choose the correct INSTALL_windows_* file.

Regards

Markus Wanner



_______________________________________________
Monotone-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/monotone-devel

[Stephen Leake-3]

Markus Wanner <[hidden email]> writes:

> Stephen,
>
> On 05/03/2014 03:54 PM, Stephen Leake wrote:
>> I've built nvm.msys2-mingw-64 with Mys2/MingW64 64 bit. It passes all tests
>> except one func test (empty_environment) and some extra tests.
>
> Cool, thanks.
>
> What goes wrong in empty_environment? That one works on Msys 1.0.

The commit gives:

stderr:
mtn: beginning commit on branch 'testbranch'
mtn: error: sqlite error: SQL logic error or missing database

I'm guessing it's a library issue, combined with the weird way msys2
works.

>> I need to test that branch on a Unix box (I have Debian and Cygwin),
>> since most of the changes are in '#ifdef Windows' areas.
>
> I just tried: There are a couple of places where Unix needs an argument
> that you've commented out. Please revert those.

Done in nvm.cleanup-warnings.

> Also, I'm not a fan of the cast to void hack. That clutters the source
> code quite a bit - especially when you need additional ifdefs to filter
> based on platform. I'd rather disable that warning.

I reviewed all the FIXME-UNUSED, and deleted some because they were not
needed. So -Wno-unused is useful.

There's not much clutter; I think it's worth the gain.

> Please also teach your editor to not re-indent code you didn't touch.
> That greatly eases review.

It didn't reindent, but it did remove tabs. I'll change that.

>> See INSTALL_windows_msys2_64.txt for tools install; there is also
>> INSTALL_windows_msys2_32.txt, which is very similar, but has "32"
>> instead of "64" in lots of places. Having two different files makes it
>> easier to cut and paste the commands.
>
> I appreciate your efforts to document the build process. However, please
> keep in mind that we don't provide half the amount of instructions on
> building on any other OS.

I think we should; there's nothing worse than trying to follow some
install instructions only to discover there is some crucial bit of
information missing.

For example, are the Botan args to configure necessary on Debian? I just
assume so (because they are required on cygwin and msys2), but I didn't
check. If I had not done the msys2 install first, I would not have known
to use them, and would have wasted time figuring that out for Debian.

What is the downside of having explicit, complete, instructions?

On the other hand, a large part of INSTALL_windows_msys2_64.txt talks
about how to install msys2. That sort of instruction is not required for
Debian and other Linux distros, because it is widely available on the
web. It is _not_ available for msys2; I had to figure it out with help
from the mailing list.

Notice that a significant portion of the messages we've exchanged are
about "what tools are you using?". Having identical tool setups is
essential to tracking down bugs.

> Already before those additions, I felt the
> urge to merge, simplify and reduce the information into one file.

Why?

That will make it harder to follow, which means more likely to get it
wrong.

There are only 100 lines in INSTALL_windows_msys2_64.txt.

We could factor out the 'install msys2' part, but I don't see the point.

> I think exact commands should go into a script or on the wiki, if yo
> want. In the source tree, I'd say a single INSTALL_windows.txt showing
> different build options and outlining special considerations for Windows
> should suffice.

I don't understand the rationale for moving stuff to the wiki. That's
harder to edit, and it won't be kept up to date.

> As it stands, an average Windows user would need a guide on how to
> choose the correct INSTALL_windows_* file.

We are not addressing the average Windows user - that's my mom and
siblings, who read email but never compile anything.

We are addressing people who want to compile monotone. That's me and
you and a few others. I find these instructions necessary, and I'm doing
the work of maintaining them; what's the downside?

The guide is in INSTALL (just updated in nvm.msys2-mingw-64). I suggest
we delete INSTALL_windows_mingw.txt.

--
-- Stephe

_______________________________________________
Monotone-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/monotone-devel

[Markus Wanner-2]

Stephen,

On 05/04/2014 03:48 PM, Stephen Leake wrote:
> Done in nvm.cleanup-warnings.

Cool, thanks. I'll have another look, soon.

> I think we should; there's nothing worse than trying to follow some
> install instructions only to discover there is some crucial bit of
> information missing.

Yes, there is something worse than missing parts: Wrong parts. And
out-dated stuff is pretty darn close to be wrong.

The MinGW instructions prior to the recent release were helpful to some
extent, but a lot of it was out-dated. I had to figure which parts still
apply and which not. Granted, I didn't use the versions indicated in the
doc. I wanted newer stuff. And I wish I had a more general, less verbose
guide.

Put another way: I just don't think we can keep up install instructions
with that much detail for every of at least three different windoze
build environments.

> For example, are the Botan args to configure necessary on Debian?

Depends on which version of Botan you want to compile against. Maybe you
even want to compile against a self-compiled one in a custom location.
We cannot possible cover all variants - nor should we.

> I just
> assume so (because they are required on cygwin and msys2), but I didn't
> check. If I had not done the msys2 install first, I would not have known
> to use them, and would have wasted time figuring that out for Debian.

Configure tells you pretty clearly if it found what it needs or what's
missing, if it didn't. Reading through pages of outdated options on how
I don't want to do it would certainly waste much more time for me, thanks.

> On the other hand, a large part of INSTALL_windows_msys2_64.txt talks
> about how to install msys2. That sort of instruction is not required for
> Debian and other Linux distros,

Huh? If that needs explanation, please go help the mingw or msys2
project. The monotone source tree clearly is the wrong place to put that
documentation, as most users in need for it won't find it, there.

> Notice that a significant portion of the messages we've exchanged are
> about "what tools are you using?". Having identical tool setups is
> essential to tracking down bugs.

I don't think we're in the position to enforce a tool chain on your
users. The best we can do is make monotone easy to compile on most
platforms.

Instead of a lengthy document, why not bundle the entire set of tools
required to build monotone in a zip file ready to delpoy? That would
save the tedious work of accurately following 100 lines of boring
instructions.

> Why?
>
> That will make it harder to follow, which means more likely to get it
> wrong.

No, a more concise variant without exact commands or version numbers
(which I neither want nor find anymore) would have been way easier to
follow for me. Heck, I'm not a script interpreter.

> I don't understand the rationale for moving stuff to the wiki. That's
> harder to edit, and it won't be kept up to date.

Wikis hard to edit? Do we use the same Internet?

To me, the existing instructions felt more like a protocol of your
experience getting monotone to compile from source on Windows. That's
fine and certainly helpful to some point. But the source tree isn't the
right place for a protocol, IMO.

>> As it stands, an average Windows user would need a guide on how to
>> choose the correct INSTALL_windows_* file.
>
> We are not addressing the average Windows user - that's my mom and
> siblings, who read email but never compile anything.

Okay. Point taken. Who are we writing this for? The average Windows
developer?

> We are addressing people who want to compile monotone. That's me and
> you and a few others. I find these instructions necessary, and I'm doing
> the work of maintaining them; what's the downside?

If you're really going to maintain all of those multiple variants, I can
live with it. I still want the rough guide on how to compile if I don't
follow your instructions line by line.

Thanks for writing up something for INSTALL, I'll review.

Regards

Markus Wanner


_______________________________________________
Monotone-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/monotone-devel

[Stephen Leake-3]

Markus Wanner <[hidden email]> writes:

> Stephen,
>
> On 05/04/2014 03:48 PM, Stephen Leake wrote:
>> Done in nvm.cleanup-warnings.
>
> Cool, thanks. I'll have another look, soon.
>
>> I think we should; there's nothing worse than trying to follow some
>> install instructions only to discover there is some crucial bit of
>> information missing.
>
> Yes, there is something worse than missing parts: Wrong parts. And
> out-dated stuff is pretty darn close to be wrong.

I disagree. The doc is accurate at a point in time; as long as that is
clear, people understand things change.

> The MinGW instructions prior to the recent release were helpful to some
> extent, but a lot of it was out-dated. I had to figure which parts still
> apply and which not. Granted, I didn't use the versions indicated in the
> doc. I wanted newer stuff. And I wish I had a more general, less verbose
> guide.

What would you suggest? I have no problem adding more stuff, but I
thought you wanted to reduce, not increase.

> Put another way: I just don't think we can keep up install instructions
> with that much detail for every of at least three different windoze
> build environments.

Well, I was only maintaining mingw. Now I've switched to maintaining
msys2-mingw2-32 and -64. If no one steps up to maintain the others, they
should be deleted.

>> For example, are the Botan args to configure necessary on Debian?
>
> Depends on which version of Botan you want to compile against. Maybe you
> even want to compile against a self-compiled one in a custom location.
> We cannot possible cover all variants - nor should we.

True. And the files don't claim to.

The point is to have one known working install, for people just getting
started on a new platform. Once they get that working, they can mess
around to build it differently.

>> I just
>> assume so (because they are required on cygwin and msys2), but I didn't
>> check. If I had not done the msys2 install first, I would not have known
>> to use them, and would have wasted time figuring that out for Debian.
>
> Configure tells you pretty clearly if it found what it needs or what's
> missing, if it didn't.

Yes, but it does _not_ tell you how to fix it. Why would I imagine that
I should add "-I/usr/include/botan-1.10", when aptitude confirms that I
installed the botan devel package?

> Reading through pages of outdated options on how
> I don't want to do it would certainly waste much more time for me,
> thanks.

In the debian case, and in msys2, it is not "pages of outdated options".
MinGW was worse, but it's obsolete now.

>> On the other hand, a large part of INSTALL_windows_msys2_64.txt talks
>> about how to install msys2. That sort of instruction is not required for
>> Debian and other Linux distros,
>
> Huh? If that needs explanation, please go help the mingw or msys2
> project.

I tried that; they are not interested. I find that many open source
projects are not interested in good docs; apparently it's less fun than
code. git is _much_ worse than monotone; it's one of the many things I
like about monotone.

> The monotone source tree clearly is the wrong place to put that
> documentation, as most users in need for it won't find it, there.

I agree that non-monotone msys2 users won't find it there.

As a work-around until the msys2 project improves their docs, this makes
the most sense to me.

>> Notice that a significant portion of the messages we've exchanged are
>> about "what tools are you using?". Having identical tool setups is
>> essential to tracking down bugs.
>
> I don't think we're in the position to enforce a tool chain on your
> users.

I'm not "enforcing" anything; merely documenting one known configuration
that does work.

> The best we can do is make monotone easy to compile on most
> platforms.

Yes. And "easy" means "here are all the options I had to sweat to figure
out, so you don't have to".

I agree that doesn't help if the doc is significantly out of date (as
mingw was). I don't see how a less specific doc can be _more_ helpful.

> Instead of a lengthy document,

100 lines is _not_ "lengthy".

If you want a _lengthy_ tools install document, see
http://gds.gsfc.nasa.gov/tools_install_linux_developer.pdf (32 pages).
That's what I use for work. I would be utterly lost without it.

> why not bundle the entire set of tools required to build monotone in a
> zip file ready to delpoy?

Because that most likely won't work as time goes by. The install docs
give enough information to catch up to new versions when necessary.

> That would save the tedious work of accurately following 100 lines of
> boring instructions.

If someone can't follow 100 lines of boring instructions to get a working
system, they are not likely to be much help to the monotone project.

Unless we do provide a tools installer, the same amount of tedious work
has to be done anyway; I don't see how it would be better to have to
also figure out each step along the way. I guess it could be more fun,
but I'd rather save my brain power for the project, not waste it on the
tools.

>> I don't understand the rationale for moving stuff to the wiki. That's
>> harder to edit, and it won't be kept up to date.
>
> Wikis hard to edit?

Yes; editing a wiki is harder than editing a text file on my local disk,
in the same directory as the rest of monotone.

And yes, the wiki/browser GUI interface is much harder to use than
Emacs.

>Do we use the same Internet?

The internet has many faces; we probably use quite disjoint sets.

> To me, the existing instructions felt more like a protocol of your
> experience getting monotone to compile from source on Windows.

Yes, that's what it is. It doesn't claim to be anything else.

That's exactly what I look for when I need to compile a new project on a
new platform.

--
-- Stephe

_______________________________________________
Monotone-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/monotone-devel

[Markus Wanner-2]

Stephen,

I understand your point of view and appreciate your efforts. Please
continue to maintain the msys2 documentation.

I'm not quite satisfied with the general guide for Windows, though, so
please allow me to write something. I think that may well fit into
INSTALL itself.

Do you have any useful hints for what build system to choose for
Windows? I mean Cygwin vs the others is somewhat obvious - either you
want that POSIX emulation layer or you don't. But all of the MinGW
versions confuse me a lot. Why did you choose MinGW64 over MinGW-w64 (!)
[0], for example? What about the different C++ exception and threading
models? Which one did you (or mingw/msys2) use? What effect do these
options possibly have on monotone? Let alone the issue of
cross-compiling 32-bit binaries from a 64-bit system & tool chain. (And
vice versa?) And then there is also MSVC...

Granted, most of that should be MinGW / Msys / MinGW-w64 project
documentation. And I certainly agree with you that their docs need some
love. I find it hard to believe they are not interested in good
documentation. Maybe they are not interested in monotone build
protocols, yes.

Of course, we cannot ever test all possible combinations. We don't do
that on any Unix, either. But rather than listing just one or two very
specific combinations, we can still state the options, their
requirements, what's known to work or fail (for example the issue you
faced with gcc 4.6.2).

FWIW, I also plan to keep my buildbot on msys 1.0, for now. While I
don't intend to maintain the INSTALL_windows_mingw.txt document to the
level of detail you used to do it, I'd still like to keep something in
there that clarifies that MinGW / Msys 1.0 is known to work. Dropping
the file, as you suggested, would lose that knowledge.

I'll eventually write up something.

Regards

Markus Wanner


[0] the MinGW-w64 download page:
http://mingw-w64.sourceforge.net/download.php



_______________________________________________
Monotone-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/monotone-devel

[Markus Wanner-2]

Stephen,

On 05/04/2014 03:48 PM, Stephen Leake wrote:
>> I just tried: There are a couple of places where Unix needs an argument
>> that you've commented out. Please revert those.
>
> Done in nvm.cleanup-warnings.

No, I still found lots crufty casts to void like this one:

@@ -2384,6 +2457,10 @@ CMD_AUTOMATE(get_workspace_root, "",
              "",
              options::opts::none)
 {
+  (void)execid;
+  (void)output;
+  (void)args;
+
   workspace work(app);
   output << get_current_working_dir() << '\n';
 }

Without explanation, lots of readers of that code, who didn't happen to
follow this thread (or even myself in three years from now) will ask
themselves: WTF? (See multiple instances of that on stackoverflow.)

Rather than adding even more clutter in the form of a comment about
compiler happiness or some such, let's please just keep that warning
disabled. It's gain-to-pain ratio is way too low.


Note that we use "-Wno-unused" since 2006 (c1ecd781). The only thing
that's "new" is that gcc 4.8 now emits that "unused parameter" warning
even though "-Wno-unused" is given (my gcc 4.7 doesn't do that).


Here are some warning counts for recent revs in nvm.cleanup-warnings.
All from my Debian testing box; number of warnings for these compilers
in the following order: gcc 4.7.3, gcc 4.8.2, clang 3.4; n/a means I
didn't check.

f2f237f5.. (your last commit):       0    7   156
491b5798.. (I merged with nvm):     n/a   7   156
882e1fd0.. (add -Wno-unused-param):  0    7   154
1b013c9f.. (revert casts to void):  n/a   7   148 (note the drop!)
a9efe468.. (cleanup gcc warn):      n/a   0   148
bfc3656a.. (cleanup clang warn):     0    0    0


If you want to make an argument about enabling warnings on unused things
in general, please try dropping the "-Wno-unused" and check the warnings
that arise.

I can imagine enabling some of the currently disabled gcc warnings. The
unused-but-set-* ones seem useful on the surface, for example. Consider
that AC_PROG_CXX_WARNINGS doesn't currently distinguish between gcc and
clang (3.4), though. And their set of supported options certainly
differs slightly. I tried enabling -Wusused-but-set-variable, but clang
doesn't understand that, for example. Also mind older versions...
Overall, to me this just doesn't seem worth the trouble.


And generally speaking, there are unused things which may become useful
at some point in time. I don't feel confident deleting all of those
things. After all, you didn't delete the parameter name for the very
same reason, but commented it out: You wanted to keep the name there, in
case it becomes useful.


None the less, I also fixed a couple "unused-variable" and
"unused-local-typedef" warnings in a9efe468. Those were obvious
left-overs and useful hints from the compiler. But manually selected and
checked; I intentionally left other things in there, which some compiler
thinks are unused, but didn't seem useless to me.

I hope this still satisfies your needs and allows you to "work much
better when there are no spurious warnings".

Regards

Markus Wanner



_______________________________________________
Monotone-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/monotone-devel

[Stephen Leake-3]

Markus Wanner <[hidden email]> writes:

> I understand your point of view and appreciate your efforts. Please
> continue to maintain the msys2 documentation.

Ok, thanks.

> I'm not quite satisfied with the general guide for Windows, though, so
> please allow me to write something. I think that may well fit into
> INSTALL itself.

Ok.

> Do you have any useful hints for what build system to choose for
> Windows? I mean Cygwin vs the others is somewhat obvious - either you
> want that POSIX emulation layer or you don't.

Right.

> But all of the MinGW versions confuse me a lot. Why did you choose
> MinGW64 over MinGW-w64 (!) [0], for example?

There are a lot of ways to use MinGW64; it is confusing.

I did not try them all; I only tried downloading from the MinGW64 site,
and the Msys2 site.

I went with Msys2 because it has a good package manager, an almost
complete set of packages for monotone (only Botan needed to be compiled
from source), can run autotools and configure, and a helpful email list.

> What about the different C++ exception and threading models? Which one
> did you (or mingw/msys2) use?

It was chosen by Msys2 when they packaged MinGW64; I don't know which
they picked. It should be possible to find out from the Msys2 project.
But at this point, I also don't care :).

> What effect do these options possibly have on monotone?

No idea, except it's pretty minor. We use exceptions for error handling,
not for mainline processing.

> Let alone the issue of cross-compiling 32-bit binaries from a 64-bit
> system & tool chain.

The tool chain installed in msys2/mingw32 is a 32 bit toolchain.

At the moment, it Just Works, so I'm happy.

> (And vice versa?) And then there is also MSVC...

I've never installed MSVC; I see no reason to. But apparently some
people do: more power to them.

> Of course, we cannot ever test all possible combinations. We don't do
> that on any Unix, either. But rather than listing just one or two very
> specific combinations, we can still state the options, their
> requirements, what's known to work or fail (for example the issue you
> faced with gcc 4.6.2).

I prefer to just list the one known working config; that's hard enough.
No one has ever asked for anything more (until you, now).

> FWIW, I also plan to keep my buildbot on msys 1.0, for now. While I
> don't intend to maintain the INSTALL_windows_mingw.txt document to the
> level of detail you used to do it, I'd still like to keep something in
> there that clarifies that MinGW / Msys 1.0 is known to work. Dropping
> the file, as you suggested, would lose that knowledge.

It didn't work for me, so "known to work" is not true, I think. It would
be best if more than one person was able to follow the install script
and succeed.

By that standard, msys2 isn't "known to work", either :(.

Cygwin also didn't work for me.

Sometimes it's just that no two Windows boxes are ever the same; it is
frustrating.

> I'll eventually write up something.

Ok.

--
-- Stephe

_______________________________________________
Monotone-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/monotone-devel

[Stephen Leake-3]

Markus Wanner <[hidden email]> writes:

> Stephen,
>
> On 05/04/2014 03:48 PM, Stephen Leake wrote:
>>> I just tried: There are a couple of places where Unix needs an argument
>>> that you've commented out. Please revert those.
>>
>> Done in nvm.cleanup-warnings.
>
> No, I still found lots crufty casts to void like this one:
>
> @@ -2384,6 +2457,10 @@ CMD_AUTOMATE(get_workspace_root, "",
>               "",
>               options::opts::none)
>  {
> +  (void)execid;
> +  (void)output;
> +  (void)args;
> +
>    workspace work(app);
>    output << get_current_working_dir() << '\n';
>  }
>
> Without explanation, lots of readers of that code, who didn't happen to
> follow this thread (or even myself in three years from now) will ask
> themselves: WTF? (See multiple instances of that on stackoverflow.)

We could add this idiom to HACKING if we keep it. But I agree it's best
to not keep the warnings enabled.

> Rather than adding even more clutter in the form of a comment about
> compiler happiness or some such, let's please just keep that warning
> disabled. It's gain-to-pain ratio is way too low.

Apparently we disagree on that. All my work projects require that warning.

> Note that we use "-Wno-unused" since 2006 (c1ecd781).
> The only thing that's "new" is that gcc 4.8 now emits that "unused
> parameter" warning even though "-Wno-unused" is given (my gcc 4.7
> doesn't do that).

Ah; I misread that option; it's trying to _suppress_ the warnings, not
enable them.

> If you want to make an argument about enabling warnings on unused things
> in general, please try dropping the "-Wno-unused" and check the warnings
> that arise.

Yes, that would make sense.

> I can imagine enabling some of the currently disabled gcc warnings. The
> unused-but-set-* ones seem useful on the surface, for example. Consider
> that AC_PROG_CXX_WARNINGS doesn't currently distinguish between gcc and
> clang (3.4), though. And their set of supported options certainly
> differs slightly. I tried enabling -Wusused-but-set-variable, but clang
> doesn't understand that, for example. Also mind older versions...
> Overall, to me this just doesn't seem worth the trouble.

Ok.

> And generally speaking, there are unused things which may become useful
> at some point in time. I don't feel confident deleting all of those
> things. After all, you didn't delete the parameter name for the very
> same reason, but commented it out: You wanted to keep the name there, in
> case it becomes useful.

No, I kept it there so the implementation corresponds to the spec.

> None the less, I also fixed a couple "unused-variable" and
> "unused-local-typedef" warnings in a9efe468. Those were obvious
> left-overs and useful hints from the compiler. But manually selected and
> checked; I intentionally left other things in there, which some compiler
> thinks are unused, but didn't seem useless to me.

Yes, g++ doesn't always get it right; that's an argument in favor of
suppressing the warning.

> I hope this still satisfies your needs and allows you to "work much
> better when there are no spurious warnings".

Yes, as long as there are no warnings in the compiler output, my
workflow works :).

We should add something about this in HACKING, and perhaps suggest
compiling new code with -Wunused enabled, to catch bugs before they get
too far.

--
-- Stephe

_______________________________________________
Monotone-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/monotone-devel

[Markus Wanner-2]

On 05/06/2014 02:15 AM, Stephen Leake wrote:
> Yes, as long as there are no warnings in the compiler output, my
> workflow works :).

I'm glad to hear that.

Anything speaking against landing nvm.cleanup-warnings, then?

> We should add something about this in HACKING, and perhaps suggest
> compiling new code with -Wunused enabled, to catch bugs before they get
> too far.

Yeah. One hurdle there is that you cannot just pass that in CXXFLAGS,
but have to adjust m4/prog_cxx_warnings.m4. :-(

Regards

Markus Wanner



_______________________________________________
Monotone-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/monotone-devel

[Stephen Leake-3]

Markus Wanner <[hidden email]> writes:

> On 05/06/2014 02:15 AM, Stephen Leake wrote:
>> Yes, as long as there are no warnings in the compiler output, my
>> workflow works :).
>
> I'm glad to hear that.
>
> Anything speaking against landing nvm.cleanup-warnings, then?

No, go ahead.

I'd like to test nvm.msys2-mingw-64 on a 64 bit linux before landing
that; I have Redhat 6 64 bit.

>> We should add something about this in HACKING, and perhaps suggest
>> compiling new code with -Wunused enabled, to catch bugs before they get
>> too far.
>
> Yeah. One hurdle there is that you cannot just pass that in CXXFLAGS,
> but have to adjust m4/prog_cxx_warnings.m4. :-(

I would just edit the Makefile after configure. I do that to change -O2
to -O0 for debugging, as well.

--
-- Stephe

_______________________________________________
Monotone-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/monotone-devel

[Stephen Leake-3]

Stephen Leake <[hidden email]> writes:

> I'd like to test nvm.msys2-mingw-64 on a 64 bit linux before landing
> that; I have Redhat 6 64 bit.

Done, and passing.

Any objections to propagating nvm.msys2-mingw-64 to nvm?

--
-- Stephe

_______________________________________________
Monotone-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/monotone-devel

[Markus Wanner-2]

On 05/16/2014 11:34 AM, Stephen Leake wrote:
> Stephen Leake <[hidden email]> writes:
>> I'd like to test nvm.msys2-mingw-64 on a 64 bit linux before landing
>> that; I have Redhat 6 64 bit.
>
> Done, and passing.
>
> Any objections to propagating nvm.msys2-mingw-64 to nvm?

No, looks fine from here. Cleared to land.

Regards

Markus Wanner



_______________________________________________
Monotone-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/monotone-devel

[Stephen Leake-3]

Markus Wanner <[hidden email]> writes:

> On 05/16/2014 11:34 AM, Stephen Leake wrote:
>> Stephen Leake <[hidden email]> writes:
>>> I'd like to test nvm.msys2-mingw-64 on a 64 bit linux before landing
>>> that; I have Redhat 6 64 bit.
>>
>> Done, and passing.
>>
>> Any objections to propagating nvm.msys2-mingw-64 to nvm?
>
> No, looks fine from here. Cleared to land.

Done.

Then propagated nvm to nvm.mandatory-cxx11, so I can test with msys2 mingw64

--
-- Stephe

_______________________________________________
Monotone-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/monotone-devel