Hi Jiri, >>>> I think that is the right time to start with arch dependent >>>> compilation. >>>> Here is the patch which solve my problem with hyperthreading >>>> compilation. >>>> >>>> Mike: Any comments? If not I'll prepare proper patch for Subrata. >>>> >>>> --- a/Makefile >>>> +++ b/Makefile >>>> +ifndef ARCH >>>> +ARCH=i386 >>>> +endif >>>> >>> >>> this is no good imo. the ARCH should either be discovered >>> automatically, or >>> not at all. >>> >> Arch should be discover automatically for systems where you compile LTP >> but not when you cross compile on x86 for different arch. > > In that case, "not at all" applies. Also, the change you've posted > raises several questions > > - why do you add a macro ARCH, that is generally not used in the LTP? I think that it the right time to start with ARCH depended compilation -> I mean as target arch. > - why resort to 386, and not x86-64, sparc or powerpc >From my point of view is the question not important for me. I do Microblaze and I believe that in the main Makefile Microblaze won't be as default arch. This is question on x86 guys.
> > Also, the compiler really should set architecture spcific macros based > on the target. I don't know full LTP history but I think that is primary focus on x86 where is target the same arch where is LTP compiled. I believe that people tried to compile LTP on x86 for another arch. That's my case and I just trying to solve build problems which I have. I can fix easily fix it in my private tree but I think that this help me or microblaze community but in general the problem will be there. I don't want to manage patches and take care about them. That's why I would like to solve it directly in LTP. And this discuss is only about how to do it in right way. > >>> >>>> --- a/testcases/kernel/sched/Makefile >>>> +++ b/testcases/kernel/sched/Makefile >>>> +ifeq ($(ARCH),i386) >>>> +SUBDIRS += hyperthreading >>>> +endif >>>> >>> >>> i thought the code already had #ifdef's in it you could fix up easily ? >>> -mike >>> >> Some ifdefs are there but the question is why we should compile tests >> which we don't need for non x86 arch. > > ... and the answer is yes, and the rationale is that we want that the > tests not fail on non x86 architectures, and for this, we need the > files to be there. I understand that some fake tests are good for finding bugs on another arch but these feature don't break any compilation for all arch but not tests which only write answer that this test cannot be run on this arch. > >> Ifdef which are there are only for i[3-6]86. This covered only cases >> when you compile ltp on powerpc for powerpc test - that's work. >> Adding more ifdef to code seems to me useless. > > Why would you need to add ifdefs? Does a simple s/ARCH_i386/__i386__/g > not work for you? I believe that this can work but there is still question why and I have no problem to have it there but... Please look at testcases/kernel/hyperthreading/ht_affinity/HTaffinity.c to lines 229-235. There is part of code for different arch -> Maybe I am missing something but I can't realize what can bring me this test. I see there -> wasting compilation time, wasting space on rootfs, log, website, wasting time for checking which test failed. I hear you that you think that everywhere is a lot of space and compilation time is no problem on current machine but every wasting is wrong. Subrata: If is OK Jiri's proposal for you or you don't want to add any different solution(more general) I am OK with it but I still feel that we can do it in different (more general) way but fix my problem. If yes? Do I generate patch for it or you Jiri? Thanks, Michal -- Michal Simek, Ing. (M.Eng) PetaLogix - Linux Solutions for a Reconfigurable World w: www.petalogix.com p: +61-7-30090663,+42-0-721842854 f: +61-7-30090663 ------------------------------------------------------------------------------ Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H _______________________________________________ Ltp-list mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ltp-list
