Have fun setting up OpenVPN tray icon, sucker



  • Hey, @tar....

    @riking said:

    That sounds on about the same level, to me, as shipping a Makefile with -Wall -Werror included in the default build.

    @tar said:

    Are you implying that -Wall -Werror is going to break on properly-written portable code?

    @cartman82 said:

    Change AM_INIT_AUTOMAKE([foreign -Wall -Werror]) to AM_INIT_AUTOMAKE([foreign -Wnone])

    You were saying?



  • WHAT WAS I SAYING?!?!?

    @tar said:

    Are you implying that -Wall -Werror is going to break on properly-written portable code?

    @tar said:

    properly-written portable

    Oh, right....



  • Oops, forgot to write it down...

    My point is that "properly-written portable code", in the sense that it will never trigger any warnings on any compiler you ever compile it with, is so low in quantity as to be insignificant.



  • I'm not 100% convinced of that—my C++ code compiles with -Wall -Werror -Wextra on Windows, Linux or BSD with pretty much any gcc from 4.6 onwards, and a reasonably modern clang (clang is actually much stricter on template code than gcc is—if your template code compiles on clang, it'll compile on gcc...)

    Noew, I do have a few -Wno- set flags for things such as "unused function parameter" (and I do negotiate with any particular compiler to decide precisely which -Wno- flags it understands from the set that I test against). And I don't use -Werror with third party code I depend on (say, SDL, or SQLite). But you can write things like an audio plugin network or an OpenGL renderer under those conditions. It's mildly annoying to have to maintain, but it's doable


  • Discourse touched me in a no-no place

    @tar said:

    I'm not 100% convinced of that—my C++ code compiles with -Wall -Werror -Wextra on Windows, Linux or BSD with pretty much any gcc from 4.6 onwards, and a reasonably modern clang (clang is actually much stricter on template code than gcc is—if your template code compiles on clang, it'll compile on gcc...)

    That's fine until you have software that uses a deprecated OS API (and where what it is deprecated in favour of totally lacks the functionality you're using, of course; some parts of OSX are exactly like that when you want to do advanced virtualisation of library loading). At that point, you're stuck with having warnings. The best you can usually do in that case is to corral the errors into one file that you build without -Werror and turn the flag on for everything else.



  • @cartman82 said:

    > 2. Build it

    $ cd gopenvpn
    $ autoreconf -vi

    🤦

    That’s a major pet peeve of mine: Projects that use automake, but whose source distribution doesn’t include the generated configure script, so you have to manually call autogen.sh, autoreconf or other mystic incantation.


    Filed under: Want clear messages about missing libraries? Ha! Have fun with `AM_CHECK_WHATEVER is not defined`

  • Discourse touched me in a no-no place

    @VinDuv said:

    That’s a major pet peeve of mine: Projects that use automake, but whose source distribution doesn’t include the generated configure script, so you have to manually call autogen.sh, autoreconf or other mystic incantation.

    We <!-- the Tcl project; work is all mavenized Java --> keep that stuff committed in our repo. Yes, that's a bit wrong. No, it's not a catastrophic problem in practice; we don't change that part of the build system very often. 😄


  • Winner of the 2016 Presidential Election

    I use IntelliJ for pretty much everything I do, and I like to make sure that the little bar on the side is always green - That means I'll go through after I've written code and clean it up as much as possible, then annotate out anything that I can't clean (With comments to indicate why, of course).



  • IMO, -Werror is an important tool, but it belongs in a form of automatic test, not in your default build, especially if you're shipping source.

    I also recomment an automatic test to verify your debug build(s) and -O0 function correctly. All of those should pass with -Werror.



  • @PleegWat said:

    -Werror is an important tool, but it belongs in a form of automatic test, not in your default build, especially if you're shipping source.

    Yeah, causing downstream maintainers to tear their hair out over a FTBFS due to a compiler version change that introduced some new, possibly-spurious warning is a bad idea.


  • Discourse touched me in a no-no place

    @dkf said:

    At that point, you're stuck with having warnings.

    Doesn't GCC have a #pragma or something to suppress a particular warning/error for a range or compilation unit?



  • You can do stuff like this (pulled out of some macros, which is why it's using _Pragma...):

        _Pragma("GCC diagnostic push")
        _Pragma("GCC diagnostic ignored \"-Winvalid-offsetof\"")
    
        // warny stuff here...
    
        _Pragma("GCC diagnostic pop") 
    

  • Discourse touched me in a no-no place

    @tar said:

    You can do stuff like this (pulled out of some macros, which is why it's using _Pragma...):

        _Pragma("GCC diagnostic push")
        _Pragma("GCC diagnostic ignored \"-Winvalid-offsetof\"")
    
        // warny stuff here...
    
        _Pragma("GCC diagnostic pop") 
    ```</blockquote>
    
    [Discoquoting rant goes <del>here</del><ins>everywhere</ins>]
    
    Dang, that's ugly.  VC++ lets you do:
    

    #pragma warning(push)
    #pragma warning(disable 4700) // you have to know what warning 4700 is, of course
    // code that generates 4700 here
    #pragma warning(pop)



  • It'd probably be more like this if you used #pragma:

    #pragma GCC diagnostic ignored "-Winvalid-offsetof"
    

    I am not sufficiently motivated to test it with a compiler though...


  • Discourse touched me in a no-no place

    @tar said:

    I am not sufficiently motivated to test it with a compiler though...

    That's still verbose.



  • I guess I don't really have as strong an opinion either way around how different compilers implement non-standard features...


  • Discourse touched me in a no-no place

    @tar said:

    I guess I don't really have as strong an opinion either way around how different compilers implement non-standard features...

    Are you agnostic on begin vs. {?



  • Pascal is just the worst.



  • OK, now you've actually made me think about it, I think the GCC #pragma has a slight edge on the CL #pragma because you don't have to go on the internet to look up the warning code to see what's being disabled. So that's an advantage which mitigates it being longer...



  • @tar said:

    OK, now you've actually made me think about it, I think the GCC #pragma has a slight edge on the CL #pragma because you don't have to go on the internet to look up the warning code to see what's being disabled. So that's an advantage which mitigates it being longer...

    Except you have to go look up what that -W string is when it happens[1]. In VC, I see the warning number when compiling, copy/paste, done. (I usually copy/paste the warning text too so I don't have to remember.)

    [1] Unless your warning generates that info too. Way too much effort to turn on my mac to see...

    @FrostCat said:

    Are you agnostic on begin vs. {?

    No one is allowed to question the one-true-style! {!


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.