[Scons-dev] Distinguishing Debian and Fedora

Tue Jan 19 10:12:46 EST 2016

I agree about the strings.

I guess I am old fashion now ( or getting there) as I tend to disagree with what modern JavaScript developers call a good practice, vs limitation of a language.

As far as detail. Certain areas like CPUs can be hard to keep up on. I know from my wonderful time at Intel, I saw that there are a lot of CPU ID. The reality most people don’t care, and if they do it most based on a feature set. Linux is the same way. 31+ flavors. An even there companies can tweak a given drop to make it different. In the end this is basically the gnu triplet problem. I have found more people don’t need the to much detail, It needed in certain cases, but it should be a fallback first the primary mean to do the work.

Jason

From: William Blevins
Sent: Tuesday, January 19, 2016 8:37 AM
To: SCons developer list
Subject: Re: [Scons-dev] Distinguishing Debian and Fedora

On Tue, Jan 19, 2016 at 1:56 PM, Jason Kenny <dragon512 at live.com> wrote:
I think this is a great idea.

However a word of warning. How this applied could break existing code people have.

Changing the env[“PLATFORM”] from posix to something like “linux” or “Linux_debian” is not backward compatible.

The reality is that a string was used for good or bad.

Strings as keys are bad most of the time; call me old fashioned, but I like strongly compiled languages which includes the ability to run pycompile and have it mean something (even if it's only a small something).

I would suggest that we defined something new so we don’t break existing build code. I know I have suggested something from parts, but I seem to have to make it a 100% independent package on pypi for it to be used by SCons.

I think we need to look at Greg’s Noel IAPAT idea. I been calling it settings and have a great start of it going on Parts. I don’t think we want do this kind of change without some thought.

I personally think we should deprecate PLATFORM and replace it with a HOST_XXX and TARGET_XXX value. Where XXX would be values like:

1)      OS ( this is abstract)
2)      OS-VARIANT/ Vender ( this is detailed)
3)      Architecture ( this is abstract)
4)      CPU-Type( this is detailed)

I am alight with this; I like enumerations, but I do not like using enumerations directly unless they are NEVER related (IE. always disjoint concepts). I think you are implying that an API should exist for this; you explain more below. I find that enumerations are generally related, so you get Set Theory applications. If we have system enums like WindowsXP, Windows7, Windows10, then we should have functions for isWindows(); otherwise, what will inevitably happen is that another enum is added and every place is the code that uses propositional logic (boolean logic) is potentially broken. I just want to make sure that adding an enum is as easy as updating a small set of functions :) 
This IMHO is very important to maintainability which for SCons and other long-term projects is a necessity.

I have found over and over again people need, as you get more low level, more detail. But to much detail can be a problem if one does not provide a good abstraction to replace it.

People need detail something like this is fedora or redhat, or the only need details such as this is windows or posix.

I know one item I would fix in the Parts Api for SystemPlatform would have been to move to use of functions for the abstract layers vs string or enums. Functions such as isX86() or isx86_64(), or isPosix or isLinux() I think will work better long term as it provides way to say useful stuff without knowing details that might change in unexpected ways. I have learned what seems good today probably will not make as much sense tomorrow, normally for reason we cannot foresee.

+10, +1 isn't enough

I should also note maintaining more detail will  have a higher maintainer cost.

Detail is fine as long as the detail has hierarchy; thus, developers can use more/less specific relationships based on need.

Jason

From: Russel Winder
Sent: Tuesday, January 19, 2016 5:42 AM
To: SCons_Developers
Subject: Re: [Scons-dev] Distinguishing Debian and Fedora

The following is a "doodle" for the direction I think the whole
platform detection thing should go. It is all about removing strings as
selectors, which has to be a bad thing given the propensity of many to
mis-spell things. 

from enum import Enum, unique

@unique
class OS_Type(Enum):
    posix = 0
    linux_debian = 1
    linux_fedora = 2
    darwin = 3
    windows_win32 = 4
    windows_cygwin = 5
    windows_mingw = 6

def which_posix():
    with open('/etc/os-release') as f:
        for line in f:
            if 'ID' in line:
                return {
                    'debian': OS_Type.linux_debian,
                    'fedora': OS_Type.linux_fedora,
                    }[line.split('=')[1].strip()]
        return OS_Type.posix

environment = Environment(
    tools=('g++', 'gnulink'),
)

platform = {
    'posix': which_posix(),
    'darwin': OS_Type.darwin,
}[environment['PLATFORM']]

environment.MergeFlags('!pkg-config --cflags --libs gtkmm-3.0')

if platform == OS_Type.linux_fedora:
    environment.MergeFlags('!pkg-config --cflags --libs gstreamermm-
0.10')
elif platform == OS_Type.linux_debian:
    environment.MergeFlags('!pkg-config --cflags --libs gstreamermm-
1.0')
else:
    print('Platform not understood.')
    Exit(1)

environment.Program('stuff.cpp', CXXFLAGS=['-std=c++14', '-W', '-
Wall'])

-- 
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder at ekiga.net
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel at winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

_______________________________________________
Scons-dev mailing list
Scons-dev at scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist2.pair.net/pipermail/scons-dev/attachments/20160119/8eb7e225/attachment.html>