> There are today ~1400 files named *.S in the tree, but none named *.s.
> So my idea was to do it like:
> *.S => *.asm => *.o
The logic is sound, but... yuck!
> Btw. this is not about "case-challenged" filesystems in general.
> This is about making the kernel usefull out-of-the-box for the
> increasing embedded market. Less work-around patces needed the
> better. And these people are oftenb ound to Windoze boxes - for
> different reasons. And the individual developer may not be able
> to change this.
The difficulty in building on a case-insensitive filesystem may
be the only hope these developers have for escaping Windows.
You turn "we must have Linux build systems to build our product"
into the less effective "we want Linux".
For the sake of these suffering developers, it would be better
to make sure that building Linux on Windows is a lost cause.
We could name a file "con" or "a:foo" for example.
Albert Cahalan wrote:
>>There are today ~1400 files named *.S in the tree, but none named *.s.
>>So my idea was to do it like:
>>*.S => *.asm => *.o
>
> The logic is sound, but... yuck!
Yes, but worth it, I think. Maybe some configure magic could
pick .asm as the suffix only when building on case-insensitive
filesystems, if that's the only way to make this palatable
to those devoted to the .s/.S idiom.
>>Btw. this is not about "case-challenged" filesystems in general.
>>This is about making the kernel usefull out-of-the-box for the
>>increasing embedded market. Less work-around patces needed the
>>better. And these people are oftenb ound to Windoze boxes - for
>>different reasons. And the individual developer may not be able
>>to change this.
>
> The difficulty in building on a case-insensitive filesystem may
> be the only hope these developers have for escaping Windows.
> You turn "we must have Linux build systems to build our product"
> into the less effective "we want Linux".
>
> For the sake of these suffering developers, it would be better
> to make sure that building Linux on Windows is a lost cause.
> We could name a file "con" or "a:foo" for example.
You are betting that you can force developers to switch away
from Windows and MacOSX workstations. That's like
trying to get someone to stop smoking. Yes, they should stop,
but nagging them will just annoy them. In particular,
they'll simply apply the patch that makes the pain go away.
We may as well be nice and apply the patch in the mainline.
- Dan
--
Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html
On Sun, 2004-10-17 at 00:38, Dan Kegel wrote:
> Albert Cahalan wrote:
> >>There are today ~1400 files named *.S in the tree, but none named *.s.
> >>So my idea was to do it like:
> >>*.S => *.asm => *.o
> >
> > The logic is sound, but... yuck!
>
> Yes, but worth it, I think. Maybe some configure magic could
> pick .asm as the suffix only when building on case-insensitive
> filesystems, if that's the only way to make this palatable
> to those devoted to the .s/.S idiom.
I'm more devoted to ".s" than I am to ".S", so if anybody
wants to rename 1400 files, go right ahead. >:-)
> >>Btw. this is not about "case-challenged" filesystems in general.
> >>This is about making the kernel usefull out-of-the-box for the
> >>increasing embedded market. Less work-around patces needed the
> >>better. And these people are oftenb ound to Windoze boxes - for
> >>different reasons. And the individual developer may not be able
> >>to change this.
> >
> > The difficulty in building on a case-insensitive filesystem may
> > be the only hope these developers have for escaping Windows.
> > You turn "we must have Linux build systems to build our product"
> > into the less effective "we want Linux".
> >
> > For the sake of these suffering developers, it would be better
> > to make sure that building Linux on Windows is a lost cause.
> > We could name a file "con" or "a:foo" for example.
>
> You are betting that you can force developers to switch away
> from Windows and MacOSX workstations.
Actually, I'm betting that "required to build product"
is a magic phrase that overrides corporate IT's desire
to brutally enforce a Microsoft-only environment.
If the developers themselves actually want Windows, well,
only a psychologist can help them.
For MacOS X, simply mount a UFS filesystem.
On Sun, Oct 17, 2004 at 01:43:56AM -0400, Albert Cahalan wrote:
> >
> > You are betting that you can force developers to switch away
> > from Windows and MacOSX workstations.
>
> Actually, I'm betting that "required to build product"
> is a magic phrase that overrides corporate IT's desire
> to brutally enforce a Microsoft-only environment.
Seems you are not part of one of these organisations.
That argument will not suffice.
Try to estimate the cost associated with the shift:
- Training
- Less efficiency in a period
- Missing important tools so a terminal service is needed
- etc.
The valid solution here would be to deploy a Linux server.
But then your arguments suffer compared to other OS'es where
everything is running on the users current host - why have
the hassle with a Linux server.
Sam
On Sunday 17 October 2004 12:27, Sam Ravnborg wrote:
> Try to estimate the cost associated with the shift:
> - Training
> - Less efficiency in a period
> - Missing important tools so a terminal service is needed
> - etc.
>
> The valid solution here would be to deploy a Linux server.
> But then your arguments suffer compared to other OS'es where
> everything is running on the users current host - why have
> the hassle with a Linux server.
One Linux addict among employees should be enough to do it.
Typically, there are some old "slow" boxes lying around
which are not usable anymore with "improved" MS OSes due to
"insufficient" RAM/disk.
--
vda
On Sun, 2004-10-17 at 05:27, Sam Ravnborg wrote:
> On Sun, Oct 17, 2004 at 01:43:56AM -0400, Albert Cahalan wrote:
> > >
> > > You are betting that you can force developers to switch away
> > > from Windows and MacOSX workstations.
> >
> > Actually, I'm betting that "required to build product"
> > is a magic phrase that overrides corporate IT's desire
> > to brutally enforce a Microsoft-only environment.
>
> Seems you are not part of one of these organisations.
> That argument will not suffice.
I was, twice, and it did suffice. Try it:
"needed for revenue generation"
"required to meet customer needs"
...
Don't be taking away the ammo.
When the argument doesn't work, your organization
is obviously not fully committed to making a profit.
Politics are getting in the way. It's OK though,
since that just puts you at a market disadvantage.
Soon enough, the competiter will be hiring.
Albert Cahalan wrote:
>>>>You are betting that you can force developers to switch away
>>>>from Windows and MacOSX workstations.
>>>
>>>Actually, I'm betting that "required to build product"
>>>is a magic phrase that overrides corporate IT's desire
>>>to brutally enforce a Microsoft-only environment.
>>
>>Seems you are not part of one of these organisations.
>>That argument will not suffice.
>
> I was, twice, and it did suffice. Try it:
>
> "needed for revenue generation"
> "required to meet customer needs"
> ...
>
> Don't be taking away the ammo.
>
> When the argument doesn't work, your organization
> is obviously not fully committed to making a profit.
> Politics are getting in the way. It's OK though,
> since that just puts you at a market disadvantage.
> Soon enough, the competiter will be hiring.
"Politics are just getting in the way"?
Boy, that's the pot calling the kettle black...
--
Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html
On Sun, 2004-10-17 at 13:16, Dan Kegel wrote:
> Albert Cahalan wrote:
> >>>>You are betting that you can force developers to switch away
> >>>>from Windows and MacOSX workstations.
> >>>
> >>>Actually, I'm betting that "required to build product"
> >>>is a magic phrase that overrides corporate IT's desire
> >>>to brutally enforce a Microsoft-only environment.
> >>
> >>Seems you are not part of one of these organisations.
> >>That argument will not suffice.
> >
> > I was, twice, and it did suffice. Try it:
> >
> > "needed for revenue generation"
> > "required to meet customer needs"
> > ...
> >
> > Don't be taking away the ammo.
> >
> > When the argument doesn't work, your organization
> > is obviously not fully committed to making a profit.
> > Politics are getting in the way. It's OK though,
> > since that just puts you at a market disadvantage.
> > Soon enough, the competiter will be hiring.
>
> "Politics are just getting in the way"?
> Boy, that's the pot calling the kettle black...
Hey, fight fire with fire.
The ".s" suffix is deeply rooted in tradition.
Since MacOS can handle case-sensitive UFS filesystems,
and it has just been reported that Microsoft SFU also
supports being case-sensitive, the problem is solved.
The only change needed is the way a library is linked.
Bummer, actually.
Albert Cahalan wrote:
> Since MacOS can handle case-sensitive UFS filesystems,
> and it has just been reported that Microsoft SFU also
> supports being case-sensitive, the problem is solved.
Not really; switching to UFS or to SFU (how often are
two unrelated acronyms in the same sentence anagrams of
each other?) is unpleasant for users accustomed to
plain old MacOSX with HFS or Windows with Cygwin.
(And politically speaking, SFU could be yanked by
Microsoft at any time, whereas Cygwin will always be
free, so I tend to support Cygwin and ignore SFU.
I have a copy of SFU, though, and if somebody asks
me to support it, I would reconsider. Nobody has yet.)
But the .S/.s ambiguity can be worked around easily
by building with 'make O=someotherdir', which is
a good idea anyway, so I'm not too worried about
it at the moment. (I'm more annoyed at ambiguities
in source file names in netfilter; see
https://lists.netfilter.org/pipermail/netfilter-devel/2004-October/017145.html)
- Dan
--
Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html