OSDev.org

Hi,

In response to your build system script that does everything and pokes what it shouldn't, I wrote a wiki article on what I think is wrong with this approach: http://wiki.osdev.org/Hard_Build_System

I encourage you to merely document what needs to be done and trust the user to do it.

I have no idea why you need to mess with /usr/bin/gcc but it scares the **** out of me. You do know there is such a thing as $PATH, right?

If you're going to grant us access to your code upon request anyways, you might as well just open it up anyway. My interest is cursory and I don't know what to expect, I'm not going to explicitly ask for access as that implies I am obligated to look closely. Chances are, if you release the sources freely, nobody is going to care in a negative way. (It's hard enough to make anyone pay mind to my freely available OS.) On a personal note, I find the source code of hobbyist operating systems much more interesting than a mere binary release or screenshots. You present nothing to play with or comment on here, I don't understand the purpose of this topic? A bit premature? But that's just my personal feelings, I'm happy to see active osdevers regardless of how far they are public releasewise. :)

As I think open software is the way, I don't see any objective in making it closed source. Think of it a little bit: every OSDever on here has its own project. Almost no one here takes care of the other ones' projects. BUT, we certainly, even not noticing it, participate other projects when answering/posting threads. Please don't misunderstand me. I'm only presenting my personal opinion. If you wanna make it privative and/or lucrative software, it's your software .

Touching the other topic; I don't know how sortie makes those stuffed wiki articles from nowhere; but that's for another thread . Think more in depth about it: what if /usr/bin/gcc isn't a symlink? That's merely possible (in a fucked up system). What if BTW it's NOT the GNU Compiler Collection, but rather something a crazy servermaster put in there? Also, if you're working in Ubuntu it's even worse. APT and friends use /usr/xxx for package-managed stuff. If you still wanna install something system-wide, do it in /usr/local/xxx at least! Or even better, modify your script to use the system's utilities.

Let's do an experiment:
1- Compile and install GCC (GNU C Compiler...) with these flags: 2- Let's run your buildscript...
3- Congratulations! You just trashed GCC with and older version! Also, you now have LOTS of bloated /usr folders due to the old GCC's libraries and runtime support. Also, you took 30 minutes to build GCC (x2 with that of your buildscript) and went nowhere!

What happens? The servermaster will come and see what you just did with his lovely GCC. The webmaster will then execute this on his terminal:

KemyLand wrote: Let's do an experiment:
1- Compile and install GCC (GNU C Compiler...) with these flags:

Code: Select all

--prefix=/usr --program-prefix=""

2- Let's run your buildscript...
3- Congratulations! You just trashed GCC with and older version! Also, you now have LOTS of bloated /usr folders due to the old GCC's libraries and runtime support. Also, you took 30 minutes to build GCC (x2 with that of your buildscript) and went nowhere!

What happens? The servermaster will come and see what you just did with his lovely GCC. The webmaster will then execute this on his terminal:

Code: Select all

sudo userdel -r you

Good one, @KemyLand

sortie wrote:You do know there is such a thing as $PATH, right?

Actually you don't need to fiddle with $PATH at all. Just use relative paths to executable files. So if you're in "/home/my_user/osdev_build/" and you want to execute "/home/my_user/osdev_build/build_tools/custom_gcc", you don't have to "sudo cp /home/my_user/osdev_build/build_tools/custom_gcc" to "/usr/bin/gcc" and then "gcc <args>" you can just "./build_tools/custom_gcc <args>" and it will do the same thing without messing up the system's gcc.